अतिक्रमण को रोकना (.NET, ASP.NET MVC)

लगभग तीन साल बीत चुके हैं जब मैंने पहली बार एक भंडार के रूप में इस तरह के अमूर्त से मेरे इनकार के बारे में लिखा था। तब से, मैंने उन प्रणालियों में किसी भी रिपॉजिटरी अवधारणाओं का व्यावहारिक रूप से उपयोग नहीं किया है जो हम विकसित कर रहे हैं। मैंने मौजूदा रिपॉजिटरी को प्रोजेक्ट्स से नहीं हटाया, लेकिन अब मुझे एब्सट्रैक्ट के रूप में कोई वैल्यू नहीं मिलती है।

डेवलपर्स द्वारा बनाए गए रिपॉजिटरी मुख्य रूप से दो प्रकार के होते हैं:

• ORM ढांचे के आस-पास के तत्व
• अनुरोधों का एनकैप्सुलेशन।

पहले मामले का उदाहरण कुछ इस तरह हो सकता है:

public interface IConferenceRepository { IRavenQueryable<Conference> Query(); Conference Load(Guid id); } 

अनुरोध एनकैप्सुलेशन आमतौर पर कुछ और लाइनें लेता है:

 public interface IConferenceRepository { IEnumerable<Conference> FindAll(); IEnumerable<Conference> FindFuture(); IEnumerable<Conference> FindFree(); IEnumerable<Conference> FindPaid(); } 

यहां, प्रत्येक विधि एक अनुरोध को एन्क्रिप्ट करती है। दोनों मामले कुछ परिदृश्यों में मूल्यवान हैं। यदि मेरा लक्ष्य मेरे ORM से विघटन करना है, तो मैं पहला रास्ता तय करूंगा, और शायद दूसरा भी चालू कर दूंगा।

लेकिन क्या ओआरएम कुछ ऐसा है जिसमें गर्भपात की आवश्यकता होती है? मुझे ऐसा नहीं लगता - ORM जैसी किसी चीज़ से अमूर्त करना मुझे अपनी शक्तिशाली कार्यक्षमता का उपयोग करने से रोकता है। ORM पहले से ही एक अमूर्त है, हमें वास्तव में खुद से पूछना है, क्या हमें अमूर्तता की अमूर्तता की आवश्यकता है ?

गहरी खुदाई

सबसे पहले, हमें इस सवाल पर वापस लौटना चाहिए कि हमने रिपॉजिटरी टेम्पलेट का उपयोग क्यों शुरू किया? निश्चित रूप से यह " परीक्षणनीयता " के नाम पर किया गया था। तो फिर कुछ इस तरह से शुरू करते हैं:

 public ActionResult Index() { RavenQueryStatistics stats; var posts = RavenSession.Query<Post>() .Include(x => x.AuthorId) .Statistics(out stats) .WhereIsPublicPost() .OrderByDescending(post => post.PublishAt) .Paging(CurrentPage, DefaultPage, PageSize) .ToList(); return ListView(stats.TotalResults, posts); } 

जटिल लगता है? नहीं। यद्यपि यदि जटिलता बढ़ती है, तो भी हम इसके दायरे को अकेले इस एक विधि तक सीमित रखेंगे। यदि हम इस अनुरोध को एक अलग वर्ग, रिपॉजिटरी या एक्सटेंशन विधि से आउटपुट करते हैं, तो अनुरोध स्वयं एक विधि में रहेगा। नियंत्रक विधि के दृष्टिकोण से, क्या यह मायने रखता है कि यह कोड कहाँ स्थित है - नियंत्रक या किसी अन्य वर्ग में?

एक अधिक जटिल उदाहरण के बारे में क्या:

 public ActionResult Archive(int year, int? month, int? day) { RavenQueryStatistics stats; var postsQuery = RavenSession.Query<Post>() .Include(x => x.AuthorId) .Statistics(out stats) .WhereIsPublicPost() .Where(post => post.PublishAt.Year == year); if (month != null) postsQuery = postsQuery.Where(post => post.PublishAt.Month == month.Value); if (day != null) postsQuery = postsQuery.Where(post => post.PublishAt.Day == day.Value); var posts = postsQuery.OrderByDescending(post => post.PublishAt) .Paging(CurrentPage, DefaultPage, PageSize) .ToList(); return ListView(stats.TotalResults, posts); } 

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

यदि मेरे पास कई अवधारणाएँ हैं, जो कि मैं नियंत्रक पद्धति में काम करता हूं, तो एक बारीकियाँ उत्पन्न होती हैं। आइए एक नियंत्रक विधि देखें, जिसमें कुछ चीजें करनी चाहिए:

 [ValidateInput(false)] [HttpPost] public ActionResult Comment(CommentInput input, int id, Guid key) { var post = RavenSession .Include<Post>(x => x.CommentsId) .Load(id); if (post == null || post.IsPublicPost(key) == false) return HttpNotFound(); var comments = RavenSession.Load<PostComments>(post.CommentsId); if (comments == null) return HttpNotFound(); var commenter = RavenSession.GetCommenter(input.CommenterKey); if (commenter == null) { input.CommenterKey = Guid.NewGuid(); } ValidateCommentsAllowed(post, comments); ValidateCaptcha(input, commenter); if (ModelState.IsValid == false) return PostingCommentFailed(post, input, key); TaskExecutor.ExcuteLater(new AddCommentTask(input, Request.MapTo<AddCommentTask.RequestValues>() ,id)); CommenterUtil.SetCommenterCookie(Response, input.CommenterKey.MapTo<string>()); return PostingCommentSucceeded(post, input); } 

इस मामले में, बहुत अधिक मान्यता है, लेकिन असली काम AddCommentTask ऑब्जेक्ट को दिया जाता है। यह एक कमांड ऑब्जेक्ट है जो MVC, सत्यापन, ActionResult और इस तरह से कार्य निष्पादन का ध्यान रखेगा।

हमने अपने अमूर्त ( AddCommentTask जैसे कार्यों) से कुछ अवधारणाएँ बनाई हैं और जिस स्थिति में हम प्रश्नों के साथ ऐसा कर सकते हैं।

परीक्षण रणनीतियाँ

आज मेरी परीक्षण रणनीति है:

• पृथक घटकों (डोमेन मॉडल और अन्य पहले से पृथक वर्ग) की इकाई परीक्षण
• एकीकरण परीक्षण सब कुछ

मैं ऑटो-मोकिंग के लिए कंटेनरों का उपयोग नहीं करता हूं। मैंने स्टब घटकों में रखा है जिन्हें मैं नियंत्रित नहीं कर सकता हूं। अन्यथा, यह तर्क को गहरे और गहरे धकेलने की रणनीति में बदल जाता है।

डेटाबेस जैसी किसी चीज़ के लिए, मेरे परीक्षण धीमे होंगे। और मैं इसे स्वीकार करना पसंद करता हूं क्योंकि इससे मुझे रिफैक्टिंग में आसानी होती है। मेरे परीक्षण सिर्फ इसलिए नहीं टूटे क्योंकि किसी तरह के स्टब को फिर से बनाने की जरूरत है।

मेरे नियंत्रकों में, मैं परीक्षण के लिए केवल एक इंटरफ़ेस ( सीम, सीम - लगभग। एड। ) पसंद करता हूं। रैकोनोब्लॉग परियोजना में , इसका मतलब है कि रेवेनडी स्टोरेज इंजन को इन-मेमोरी के साथ बदलने से मेरे परीक्षण बहुत तेज हो जाएंगे।

लेकिन फिर भी - मैं एक भंडार को जोड़ने के बारे में चिंतित नहीं हूं। मेरे अनुभव में, केवल कुछ लाने के लिए एक भंडार का परिचय देना समय की बर्बादी है। यह एक ऐसी जगह पर एक अनावश्यक अमूर्त जोड़ता है जहां किसी प्रकार की अवधारणा पर्याप्त होगी (उदाहरण के लिए, एक अनुरोध वस्तु को एनकैप्सुलेट करना)।

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

जिमी बोगर्ड हेडस्प्रिंग में एक वास्तुकार है, जो ऑटोमैपर के निर्माता और एक्शन में ASP.NET MVC के सह-लेखक हैं। अपने ब्लॉग में, वह DDD, CQRS, वितरित सिस्टम और संबंधित आर्किटेक्चर और कार्यप्रणाली पर ध्यान केंद्रित करता है।