टैम्बोरिन के साथ रिफैक्टरिंग, या हमने हल्क को कैसे शांत किया

मुझे लगता है कि हर कोई इस बात से सहमत होगा कि ज्यादातर स्टार्टअप मूल रूप से अपने घुटनों पर बने थे। तभी, एक सफल शूटिंग के मामले में, रणनीतिक लक्ष्यों के उचित मार्गदर्शन और समझ के साथ, संसाधन के मालिक मौजूदा उत्पाद को फिर से तैयार करने पर निर्णय ले सकते हैं। ठीक है, अगर यह ब्रूस बैनर के एक हल्क में परिवर्तन से पहले हुआ था। लेकिन क्या होगा अगर ऐसा क्षण सुरक्षित रूप से याद किया गया था, और संसाधन एक विशाल हरा खराब नियंत्रित विशालकाय है? ऐसी स्थिति में क्या करें?

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

इस लेख में मैं एक बहुत भ्रामक समाधान को एक आवेदन में परिवर्तित करने के अनुभव को साझा करना चाहता हूं, जिसे स्पष्ट परतों में विभाजित किया गया है और इकाई परीक्षणों के साथ कवर किया गया है। स्वाभाविक रूप से, लेख में दर्शाए गए उदाहरणों को मामूली सरल किया गया है। मेरी राय में, वे मूल अवधारणा को समझने के लिए काफी पर्याप्त हैं। शुरू करने से पहले, यह कहने योग्य है कि लेखक इकाई परीक्षण को कोड गुणवत्ता के सबसे महत्वपूर्ण संकेतकों में से एक मानता है। यह भी स्पष्ट है कि समाधान ASP.NET में Webforms का उपयोग करके लिखा गया है।

तो, चलिए शुरू करते हैं हमारे नृत्य:

पहला आंकड़ा भ्रमित है।

सबसे पहली समस्या जो हमें निपटनी थी, वह थी DAL कोड के साथ html बनाने के लिए जिम्मेदार कोड की उलझन। यह है कि, UserControl के अंदर इस तरह के एक स्क्रिबल काफी बार मिले:

StringBuilder content = new StringBuilder(); var persons = Database.Persons.GetListBySchool(school); foreach(var person in persons) { content.AppendFormat(@”<p>{0}</p>”, person.Name); } 

स्वाभाविक रूप से, इस स्थिति में, व्यक्तियों की सूची प्राप्त करने के कार्यान्वयन में किसी भी बदलाव का सपना देखने का कोई कारण नहीं है। और मैं इस कोड को यूनिट परीक्षणों के साथ कवर करने के बारे में आमतौर पर चुप रहता हूं। जल्द ही मैंने एक निर्णय लिया जो आपको UI और DAL के बीच के कनेक्शन को जल्दी और दर्द रहित रूप से तोड़ने की अनुमति देता है।

 public interface ICommand { void Execute(); } 

 public abstract class Command<T> : ICommand { public T Result { get; protected set; } public abstract void Execute(); } 

 public interface ICommandExecutor { T Run<T>(Command<T> command); } 

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

 public class GetListBySchool: Command<List<DbPerson>> { public DbSchool School { get; set; } public override void Execute() { this.Result = Database.Persons.GetListBySchool(this.School); } } 

और यहाँ ICommandExecutor कार्यान्वयन है:

 public T Run<T>(Command<T> command) { command.Execute(); return command.Result; } 

इस समाधान का उपयोग करते समय, उपयोगकर्ता नियंत्रण के अंदर कोड में बदल गया:

 private readonly ICommandExecutor executor; public SchoolView(ICommandExecutor executor) { if (executor == null) { throw new ArgumentNullException("executor"); } this.executor = executor; } public string GetPersonsHtmlList() { StringBuilder content = new StringBuilder(); var persons = this.executor.Run(new GetListBySchool { School = school }); foreach(var person in persons) { content.AppendFormat(@”<p>{0}</p>”, person.Name); } 

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

टीम इस तरह दिखने लगी:

 public class GetListBySchool: Command<List<Person>> { public long SchoolId { get; set; } public override void Execute() { var dbSchool = DataBase.Instance.GetSchoolById(this.SchoolId); this.Result = dbSchool.Network.Memberships .GetListBySchool(this.School) .Select(person => person.Convert()) .ToList(); } } 

अब हमारी GetPersonsHtmlList पद्धति पूरी तरह से परीक्षण योग्य हो गई है, हालांकि, एक और समस्या उत्पन्न हो गई है : UserControl के अंदर, ऐसी विधि केवल एक ही नहीं है, उनमें से कई हैं। और अगर पहले DbSchool ऑब्जेक्ट को केवल एक बार लोड किया गया था , तो अब इसे प्रत्येक अलग कमांड में लोड किया जाता है, और यह कम्यूट फूट नहीं है। इस समस्या को हल करने के लिए, एक IContextManager एक विधि के साथ हमारे पास आता है

 T GetFunctionResult<T>(Func<T> func) where T : class; 

हमने HttpContext.Current का उपयोग करते हुए, कार्यान्वयन से परेशान नहीं किया। यही है, अगर विधि को पहली बार कहा जाता है, तो वस्तु को संदर्भ में फेंक दिया जाता है। यदि विधि को दूसरी या अधिक बार कहा जाता है, तो ऑब्जेक्ट को संदर्भ से लिया जाता है। IContextManager का कार्यान्वयन CommandExecutor कंस्ट्रक्टर में निर्दिष्ट किया गया है, और फिर सभी कमांड्स को पास कर दिया गया है (कमांड के बेस क्लास में एक नई प्रॉपर्टी दिखाई दी है)।

 public T Run<T>(Command<T> command) { command.Context = this.context; command.Execute(); return command.Result; } 

 public class GetListBySchool: Command<List<Person>> { public long SchoolId { get; set; } public override void Execute() { var dbSchool = this.Context.GetFunctionResult(() => DataBase.Instance.GetSchoolById(this.SchoolId)); this.Result = dbSchool.Network.Memberships .GetListBySchool(this.School) .Select(person => person.Convert()) .ToList(); } } 

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

दूसरा आंकड़ा स्पष्ट है।

अगला कार्य Request.Params संग्रह से बाइंडिंग से छुटकारा पाना था। लेकिन यहां किसी के पास कोई सवाल नहीं था, और समाधान इस प्रकार था:

 public interface IParametersReader { string GetRequestValue(string key); } 

 public class RequestParametersReader : IParametersReader { private readonly HttpContextBase context; public RequestParametersReader(HttpContextBase context) { if (context == null) { throw new ArgumentNullException("context"); } this.context = context; } public string GetRequestValue(string key) { return this.context.Request[key]; } } 

तीसरा आंकड़ा हवा है।

जैसा कि आमतौर पर होता है, पृष्ठों में एक UserControl नहीं होता है, लेकिन कई का। उन सभी को समान वस्तुओं की आवश्यकता होती है। प्रारंभ में, निम्नलिखित समाधान का आविष्कार किया गया था और कार्यान्वित किया गया था: बच्चे में UserControl, एक विधि बनाई गई है

 void Bind(DbSchool school, DbPerson person) { this.school = school; this.person = person; } 

फिर विधि को पेरेंट यूजरकंट्रोल से पुकारा जाता है। सब कुछ अद्भुत लगता है, और इस तरह के निर्णय का अस्तित्व का अधिकार है। हालांकि, यह मत भूलो: जब नियंत्रण का घोंसला दो स्तरों से अधिक होता है, तो गलतियां करने या वांछित मूल्य निर्धारित करने के लिए भूलने की संभावना काफी बढ़ जाती है। समाधान के रूप में, हमने निर्भरता की अस्वीकृति के बजाय एक दिलचस्प अवधारणा का उपयोग किया। इसका मुख्य विचार पूर्व निर्धारित स्रोत से नहीं, बल्कि वस्तुओं के एक सामान्य संग्रह से डेटा प्राप्त करना है जिसे कोई भी फिर से भर सकता है। इसके लिए दो वर्ग बनाए गए:

 public class InAttribute : Attribute { public string Name { get; set; } } 

और

 public class OutAttribute : Attribute { public string Name { get; set; } } 

जिन गुणों को हवा में लटकाए जाने की आवश्यकता होती है, उन्हें आउट विशेषता के साथ चिह्नित किया जाता है। जिन गुणों को इस हवा से भरने की आवश्यकता होती है, उन्हें सादृश्य द्वारा विशेषता द्वारा चिह्नित किया जाता है। इसके अलावा, यह केवल प्रौद्योगिकी का विषय है। हमने एक वर्ग बनाया है जो System.Web.UI.UserControl से विरासत में मिला है और इसमें निम्नलिखित कोड जोड़े गए हैं:

 protected override void OnLoad(EventArgs e) { //    var inProperties = this.GetType() .GetProperties() .Where(prop => prop.GetCustomAttributes(typeof(InAttribute), false).Any()); foreach (var property in inProperties) { var inAttribute = property.GetCustomAttributes(typeof(InAttribute), false).First() as InAttribute; if (inAttribute == null) { continue; } property.SetValue( this, this.context.Get(string.IsNullOrWhiteSpace(inAttribute.Name) ? property.Name : inAttribute.Name), null); } base.OnLoad(e); //    var outProperties = this.GetType() .GetProperties() .Where(prop => prop.GetCustomAttributes(typeof(OutAttribute), false).Any()); foreach (var property in outProperties) { var outAttribute = property.GetCustomAttributes( typeof(OutAttribute), false).First() as OutAttribute; if (outAttribute == null) { continue; } this.context.Add(string.IsNullOrWhiteSpace(outAttribute.Name) ? property.Name : outAttribute.Name, property.GetValue(this, null)); } } 

उपसंहार:

यह हमारे हरे राक्षस सॉफ्टवेयर उत्पाद को फिर से तैयार करने का पहला चरण था। हमारे काम का परिणाम था:

1. यूनिट परीक्षणों के साथ UserControls को पूरी तरह से कवर करने की क्षमता।
2. यूआई परत का सब कुछ से अलग एक स्पष्ट जुदाई।
3. नेस्टेड UserContol-s के बीच तंग बंधन से छुटकारा।
4. कोड पठनीयता में सुधार।
5. नैतिक पीड़ा और विवेक की शुद्धि में कमी;)

लेख के लेखक: विटाली लेबेदेव, अग्रणी डेवलपर डायरी