गतिशील पहलू उन्मुख

एक विशिष्ट विषय मॉडल के बारे में एक कहानी, जहां कई मान्य क्षेत्र मूल्य दूसरों के मूल्यों पर निर्भर करते हैं।

कार्य

एक विशिष्ट उदाहरण का उपयोग करके जुदा करना आसान है: कई मापदंडों के साथ सेंसर को कॉन्फ़िगर करना आवश्यक है, लेकिन पैरामीटर एक दूसरे पर निर्भर करते हैं। उदाहरण के लिए, प्रतिक्रिया सीमा सेंसर, मॉडल और संवेदनशीलता के प्रकार पर निर्भर करती है, और संभव मॉडल सेंसर के प्रकार पर निर्भर करते हैं, आदि।

हमारे उदाहरण में, हम केवल सेंसर के प्रकार और उसके मूल्य (जिस सीमा पर इसे ट्रिगर किया जाना चाहिए) को लेते हैं।

public class Sensor { // Voltage, Temperature public SensorType Type { get; internal set; } //-400..400 for Voltage, 200..600 for Temperature public decimal Value { get; internal set; } } 

सुनिश्चित करें कि वोल्टेज और तापमान सेंसर के लिए मूल्य क्रमशः रेंज -400..400 और 200..600 में हो सकते हैं। सभी परिवर्तनों को ट्रैक और लॉग इन किया जा सकता है।

"सरल" समाधान

डेटा संगति बनाए रखने के लिए सबसे आसान कार्यान्वयन मैन्युअल रूप से सेटर्स और गेटर्स में प्रतिबंधों और निर्भरता को निर्धारित करना है:

 public class Sensor { private SensorType _type; private decimal _value; public SensorType Type { get { return _type; } set { _type = value; if (value == SensorType.Temperature) Value = 273; if (value == SensorType.Voltage) Value = 0; } } public decimal Value { get { return _value; } set { if (Type == SensorType.Temperature && value >= 200 && value <= 600 || Type == SensorType.Voltage && value >= -400 && value <= 400) _value = value; } } } 

एक निर्भरता बड़ी मात्रा में कोड उत्पन्न करती है जिसे पढ़ना मुश्किल है। स्थितियां बदलना या नई निर्भरता जोड़ना मुश्किल है।



एक वास्तविक परियोजना में, ऐसी वस्तुएं हमारे पास 30 से अधिक निर्भर क्षेत्र और प्रत्येक के लिए 200 से अधिक नियम हैं। वर्णित समाधान, हालांकि काम करना, ऐसी प्रणाली के विकास और समर्थन में भारी सिरदर्द लाएगा।

"आदर्श" लेकिन असत्य

नियमों को आसानी से संक्षिप्त रूपों में वर्णित किया जाता है और उन्हें उन क्षेत्रों के बगल में रखा जा सकता है जिनसे वे संबंधित हैं। आदर्श रूप में:

 public class Sensor { public SensorType Type { get; set; } [Number(Type = SensorType.Temperature, Min = 200, Max = 600, Force = 273)] [Number(Type = SensorType.Voltage, Min = -400, Max = 400, Force = 0)] public decimal Value { get; set; } } 

यदि स्थिति बदलती है तो बल को किस मूल्य पर सेट करना है।

केवल C # सिंटैक्स इसे उन विशेषताओं में लिखने की अनुमति नहीं देगा, क्योंकि उन फ़ील्ड की सूची, जिन पर लक्ष्य गुण निर्भर करता है, पूर्वनिर्धारित नहीं है।

काम करने का तरीका

हम नियमों को इस प्रकार लिखेंगे:

 public class Sensor { public SensorType Type { get; set; } [Number("Type=Temperature", "200..600", Force = "273")] [Number("Type=Voltage", "-400..400", Force = "0")] public decimal Value { get; set; } } 

यह काम करने के लिए बना हुआ है। ऐसी क्लास बस बेकार है।

डिस्पैचर

विचार सरल है - बसने वालों को बंद करें और एक निश्चित डिस्पैचर के माध्यम से फ़ील्ड मान बदलें, जो सभी नियमों को समझेंगे, उनके निष्पादन की निगरानी करेंगे, फ़ील्ड परिवर्तनों के बारे में सूचित करेंगे और सभी परिवर्तनों को लॉग करेंगे।



विकल्प काम कर रहा है, लेकिन कोड भयानक लगेगा:

 someDispatcher.Set(mySensor, "Type", SensorType.Voltage); 

आप निश्चित रूप से डिस्पैचर को निर्भरता के साथ वस्तुओं का एक अभिन्न अंग बना सकते हैं:

 mySensor.Set("Type", SensorType.Voltage) 

लेकिन मेरी वस्तुओं का उपयोग अन्य डेवलपर्स द्वारा किया जाएगा और कभी-कभी यह उनके लिए पूरी तरह से स्पष्ट नहीं होगा कि यह लिखना इतना आवश्यक क्यों है। आखिरकार, मैं बस लिखना चाहता हूं:

 mySensor.Type=SensorType.Voltage; 

विरासत

विशेष रूप से, हमारे मॉडल में, हम खुद निर्भरता के साथ वस्तुओं के जीवन चक्र को प्रबंधित करते हैं - हमने उन्हें केवल मॉडल में ही बनाया है और बाहरी रूप से केवल उनका संपादन प्रदान किया है। इसलिए, हम सभी क्षेत्रों को आभासी बना देंगे, हम मॉडल के बाहरी इंटरफ़ेस को अपरिवर्तित छोड़ देंगे, लेकिन यह पहले से ही "रैपर" की कक्षाओं के साथ काम करेगा, जो चेक के तर्क को लागू करेगा।



यह बाहरी उपयोगकर्ता के लिए एक आदर्श विकल्प है, वह इस तरह की वस्तु के साथ सामान्य तरीके से काम करेगा

 mySensor.Type=SensorType.Voltage 

यह जानने के लिए रहता है कि ऐसे रैपर कैसे बनाए जाएं

कक्षा सृजन

वास्तव में उत्पन्न करने के दो तरीके हैं:

• पूरी विशेषता-आधारित कोड बनाएँ
• विशेषता जाँच को कॉल करने वाला पूरा कोड बनाएँ

विशेषताओं के आधार पर कोड बनाना निश्चित रूप से अच्छा है और जल्दी से काम करेगा। लेकिन इसके लिए कितनी ताकत चाहिए होगी। और, सबसे महत्वपूर्ण बात, अगर आपको नए प्रतिबंधों / नियमों को जोड़ने की आवश्यकता है, तो कितने बदलावों की आवश्यकता होगी और कौन सी जटिलता?

हम प्रत्येक सेटर के लिए मानक कोड उत्पन्न करेंगे, जो उन तरीकों को कॉल करेगा जो विशेषताओं का विश्लेषण करेंगे और जांच करेंगे।

हम गेटटर को अपरिवर्तित छोड़ देंगे:

 MethodBuilder getPropMthdBldr = typeBuilder.DefineMethod("get_" + property.Name, MethodAttributes.Public | MethodAttributes.SpecialName | MethodAttributes.HideBySig | MethodAttributes.Virtual, property.PropertyType, Type.EmptyTypes); ILGenerator getIl = getPropMthdBldr.GetILGenerator(); getIl.Emit(OpCodes.Ldarg_0); getIl.Emit(OpCodes.Call, property.GetMethod); getIl.Emit(OpCodes.Ret); 

यहां, हमारी पद्धति में आया पहला पैरामीटर स्टैक पर धकेल दिया जाता है, यह ऑब्जेक्ट (यह) का एक संदर्भ है। फिर बेस क्लास के गेटर को बुलाया जाता है और रिजल्ट वापस कर दिया जाता है, जिसे स्टैक के ऊपर रखा जाता है। यानी बस बेस क्लास को कॉल करने के लिए हमारा गेट्टर।

सेटर थोड़ा पेचीदा होता है। विश्लेषण के लिए, हम एक स्थिर विधि बनाएंगे, जो विश्लेषण को लगभग निम्नलिखित तरीके से बनाएगी:

 if (StrongValidate(this, property, value)) { value = SoftValidate(this, property, value); if (oldValue != value) { <    value>; ForceValidate(baseModel, property); Log(baseModel, property, value, oldValue); } } 

StrongValidate - उन मानों को त्याग देगा जो उन लोगों में परिवर्तित नहीं किए जा सकते जो नियमों को फिट करते हैं। उदाहरण के लिए, केवल "y" और "n" को पाठ बॉक्स में लिखे जाने की अनुमति है; जब आप "u" लिखने का प्रयास करते हैं तो आपको केवल परिवर्तनों को अस्वीकार करना होगा ताकि मॉडल नष्ट न हो।

  [String("", "y, n")] 

सॉफ्टवैलिडेट - अनुचित से मान्य को मान्य में बदल देगा। उदाहरण के लिए, एक इंट फील्ड केवल संख्याओं को स्वीकार कर सकता है। जब आप 111 लिखने की कोशिश करते हैं, तो आप मूल्य को निकटतम उपयुक्त एक में बदल सकते हैं - "9"।

  [Number("", "0..9")] 

<मूल्य के साथ आधार सेटर को कॉल करें> - जब हम एक वैध मूल्य प्राप्त करते हैं, तो आपको फ़ील्ड का मान बदलने के लिए बेस क्लास के सेटर को कॉल करना होगा।

ForceValidate - परिवर्तन के बाद, हम उन क्षेत्रों में एक अमान्य मॉडल प्राप्त कर सकते हैं जो हमारे क्षेत्र पर निर्भर करते हैं। उदाहरण के लिए, बदलते प्रकार के कारण मान में परिवर्तन होता है।

लॉग सिर्फ अधिसूचना और लॉगिंग है।

ऐसी विधि को कॉल करने के लिए, हमें ऑब्जेक्ट की आवश्यकता है, इसके नए और पुराने मूल्य, और क्षेत्र जो बदल रहा है। इस तरह के एक सेटर के लिए कोड इस तरह दिखेगा:

 MethodBuilder setPropMthdBldr = typeBuilder.DefineMethod("set_" + property.Name, MethodAttributes.Public | MethodAttributes.SpecialName | MethodAttributes.HideBySig | MethodAttributes.Virtual, null, new[] { property.PropertyType }); //  ,    var setter = typeof(DinamicWrapper).GetMethod("Setter", BindingFlags.Static | BindingFlags.Public); ILGenerator setIl = setPropMthdBldr.GetILGenerator(); setIl.Emit(OpCodes.Ldarg_0);//     - this setIl.Emit(OpCodes.Ldarg_1);//     -  setter    (value) if (property.PropertyType.IsValueType) //  Boxing,    Value,         object { setIl.Emit(OpCodes.Box, property.PropertyType); } setIl.Emit(OpCodes.Ldstr, property.Name); //     setIl.Emit(OpCodes.Call, setter); setIl.Emit(OpCodes.Ret); 

हमें एक और विधि की आवश्यकता होगी जो सीधे आधार वर्ग के मूल्य को बदल देगी। कोड एक साधारण गेट्टर के समान है, केवल दो पैरामीटर हैं - यह और मान:

 MethodBuilder setPureMthdBldr = typeBuilder.DefineMethod("set_Pure_" + property.Name, MethodAttributes.Public, CallingConventions.Standard, null, new[] { property.PropertyType }); ILGenerator setPureIl = setPureMthdBldr.GetILGenerator(); setPureIl.Emit(OpCodes.Ldarg_0); setPureIl.Emit(OpCodes.Ldarg_1); setPureIl.Emit(OpCodes.Call, property.GetSetMethod()); setPureIl.Emit(OpCodes.Ret); 

छोटे परीक्षणों वाले सभी कोड यहां देखे जा सकते हैं:
github.com/wolf-off/DinamicAspect

सत्यापन

मान्यताओं के कोड स्वयं सरल हैं - वे सबसे लंबी स्थिति के सिद्धांत के अनुसार वर्तमान सक्रिय विशेषता की तलाश करते हैं और उनसे पूछते हैं कि क्या नया मूल्य वैध है। आपको नियमों को चुनते समय केवल दो चीजों पर विचार करने की आवश्यकता है (उन्हें पार्स करना और उपयुक्त लोगों की गणना करना):

• GetCustomAttributes का परिणाम कैश करें। खेतों से विशेषता लेने वाला एक कार्य धीरे-धीरे काम करता है क्योंकि यह उन्हें हर बार बनाता है। इसके परिणाम को कैश करें। मैंने बेस क्लास बेसमॉडल में लागू किया
• उपयुक्त नियमों की गणना करते समय, आपको फ़ील्ड प्रकारों से निपटना होगा। यदि सभी मान स्ट्रिंग्स और तुलना में कम हो जाते हैं, तो यह धीरे-धीरे काम करेगा। विशेष रूप से एनम। DependencyAttribute आधार विशेषता वर्ग में लागू किया गया

निष्कर्ष

इस दृष्टिकोण का क्या फायदा है?

और वह वस्तु बनाने के बाद:

 var target = DinamicWrapper.Create<Sensor>(); 

यह हमेशा की तरह इस्तेमाल किया जा सकता है, लेकिन यह विशेषताओं के अनुसार व्यवहार करेगा:

 target.Type = SensorType.Temperature; target.Value=300; Assert.AreEqual(target.Value, 300); // true target.Value=3; Assert.AreEqual(target.Value, 200); // true - minimum target.Value=3000; Assert.AreEqual(target.Value, 600); // true - maximum target.Type = SensorType.Voltage; Assert.AreEqual(target.Value, 0); // true - minimum target.Value= 3000; Assert.AreEqual(target.Value, 400); // true - maximum