स्टेरॉयड पर विनिर्देशों

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

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

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

अगला, हम अभिव्यक्ति के पेड़ की ओर मुड़ते हैं, जो एक बहुत शक्तिशाली उपकरण हैं, और देखें कि वे हमारी मदद कैसे कर सकते हैं।

अंत में, मैं स्टेरॉयड पर "विनिर्देश" के अपने कार्यान्वयन का प्रदर्शन करूंगा।

शुरुआत करते हैं मूल बातों से। मुझे लगता है कि सभी ने "विनिर्देश" पैटर्न के बारे में सुना है, लेकिन जिन लोगों ने नहीं सुना है, उनकी विकिपीडिया से परिभाषा है:

प्रोग्रामिंग में एक "विनिर्देश" एक डिज़ाइन पैटर्न है जिसके द्वारा व्यापार तर्क नियमों का प्रतिनिधित्व बुलियन तर्क संचालन द्वारा जुड़ी वस्तुओं की एक श्रृंखला में बदल सकता है।

यह टेम्पलेट व्यावसायिक तर्क में ऐसे विनिर्देशों (नियमों) को उजागर करता है जो दूसरों के साथ "युग्मन" के लिए उपयुक्त हैं। एक व्यावसायिक लॉजिक ऑब्जेक्ट सार एग्रीगेट क्लास कंपोज़ीसेफिकेशन से अपनी कार्यक्षमता विरासत में लेता है, जिसमें केवल एक IsSatisfiedBy विधि होती है जो बूलियन मान लौटाती है। तात्कालिकता के बाद, वस्तु अन्य वस्तुओं के साथ मिलकर जंजीर होती है। परिणामस्वरूप, व्यावसायिक तर्क स्थापित करने में लचीलापन खोए बिना, हम आसानी से नए नियम जोड़ सकते हैं।

दूसरे शब्दों में, एक विनिर्देश एक वस्तु है जो निम्नलिखित इंटरफ़ेस को लागू करता है (जंजीरों के निर्माण के तरीकों को छोड़ना)

public interface ISpecification { bool IsSatisfiedBy(object candidate); } 

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

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



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

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

 public class CreatedAfter: ISpecification { private readonly DateTime _target; public CreatedAfter(DateTime target) { _target = target; } bool IsSatisfiedBy(object candidate) { var character = candidate as Character; if(character == null) return false; return character.CreatedAt > target; } } 

फिर, इस विनिर्देश को लागू करने के लिए, हम निम्नलिखित करते हैं (इसके बाद मैं NHibernate आधारित कोड पर विचार करूंगा):

 var characters = await session.Query<Character>().ToListAsync(); var filter = new CreatedAfter(new DateTime(2020, 1, 1)); var newCharacters = characters.Where(x => filter.IsSatisfiedBy(x)).ToArray(); 

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

एक बार, एक बहुत, बहुत दूर की परियोजना में, मेरे पास मेरे कोड में कक्षाएं थीं जिसमें डेटाबेस से डेटा प्राप्त करने के लिए तर्क थे। वे कुछ इस तरह दिखे:

 public class ICharacterDal { IEnumerable<Character> GetCharactersCreatedAfter(DateTime date); IEnumerable<Character> GetCharactersCreatedBefore(DateTime date); IEnumerable<Character> GetCharactersCreatedBetween(DateTime from, DateTime to); ... } 

और उनका उपयोग:

 var dal = new CharacterDal(); var createdCharacters = dal.GetCharactersCreatedAfter(new DateTime(2020, 1, 1)); 

कक्षाओं के अंदर DBMS के साथ काम करने का तर्क था (उस समय यह ADO.NET था)।

सब कुछ अच्छा लग रहा था, लेकिन परियोजना के विस्तार के साथ, ये वर्ग भी बढ़ते गए, कठोर-से-बनाए वस्तुओं में बदल गए। इसके अलावा, एक अप्रिय aftertaste था - यह एक व्यापार नियम प्रतीत होता है, लेकिन उन्हें बुनियादी ढांचे के स्तर पर संग्रहीत किया गया था, क्योंकि वे एक विशिष्ट कार्यान्वयन से बंधे थे।

इस दृष्टिकोण को IQueryable <T> रिपॉजिटरी द्वारा प्रतिस्थापित किया गया था, जिसने सभी नियमों को सीधे डोमेन परत पर ले जाने की अनुमति दी थी।

 public interface IRepository<T> { T Get(object id); IQueryable<T> List(); void Delete(T obj); void Save(T obj); } 

जो कुछ इस तरह से इस्तेमाल किया गया था:

 var repository = new Repository(); var targetDate = new DateTime(2020, 1, 1); var createdUsers = await repository.List().Where(x => x.CreatedAd > targetDate).ToListAsync(); 

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

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

और यहाँ एक परियोजना पर, एक सहकर्मी ने एक पुस्तकालय का उपयोग करने का सुझाव दिया, जिसने अभिव्यक्ति के पेड़ों पर आधारित "विनिर्देश" पैटर्न के कार्यान्वयन का सुझाव दिया।

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

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

• gluing ऑपरेटर या काम नहीं किया;
• संघ केवल उन प्रश्नों के लिए काम करता है जिनमें प्रकार के फिल्टर होते हैं जहां, लेकिन मुझे समृद्ध नियम (नेस्टेड क्वेरीज़, स्किप / टेक, प्रोजेक्शन प्राप्त करना) चाहिए थे;
  
• विनिर्देशन कोड चयनित ORM पर निर्भर करता है;
• ORM सुविधाओं का उपयोग करना संभव नहीं था, जैसा कि इसके कारण व्यावसायिक तर्क परत में उस पर निर्भरता का समावेश हो गया (उदाहरण के लिए, यह करना असंभव था)।
  

इन समस्याओं को हल करने का परिणाम Singularis.Secification मिनी-फ्रेमवर्क था, जिसमें कई विधानसभाएं शामिल हैं:

• Singularis.Specification.Definition - विनिर्देश ऑब्जेक्ट को परिभाषित करता है, और इसमें IQuery इंटरफ़ेस भी होता है जिसके साथ नियम बनता है।
• Singularis.Specification.Executor। * - विशिष्ट ORM के लिए विशिष्टताओं को निष्पादित करने के लिए एक रिपॉजिटरी और एक ऑब्जेक्ट को लागू करता है (वर्तमान में ef.core और NHibernate द्वारा समर्थित है, प्रयोगों के भाग के रूप में मैंने भी मोंगोडब के लिए एक कार्यान्वयन किया था, लेकिन यह कोड उत्पादन में नहीं गया था)।

आइए कार्यान्वयन पर करीब से नज़र डालें।

विनिर्देश इंटरफ़ेस सार्वजनिक संपत्ति को परिभाषित करता है जिसमें विनिर्देश नियम शामिल हैं:

 public interface ISpecification { IQuery Query { get; } Type ResultType { get; } } public interface ISpefication<T>: ISpecification { } 

इसके अलावा, इंटरफ़ेस में ResultType संपत्ति होती है, जो क्वेरी के परिणामस्वरूप प्राप्त की गई इकाई के प्रकार को वापस करती है।

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

इसके अलावा, SpecificationExtension वर्ग भी है, जिसमें अनुरोधों को पूरा करने के लिए विस्तार विधियाँ हैं।

दो प्रकार के जुड़ने का समर्थन किया जाता है: संगति ("और" स्थिति से जुड़ने के रूप में माना जा सकता है) और "या" स्थिति से जुड़ना।

आइए अपने उदाहरण पर वापस जाएं और अपने दो नियमों को लागू करें:

 public class CreatedAfter: Specification<Character> { public CreatedAfter(DateTime target) { Query = Source().Where(x => x.CreatedAt > target); } } public class CreatedBefore: Specification<Character> { public CreatedBefore(DateTime target) { Query = Source().Where(x => x.CreatedAt < target); } } 

और उन सभी उपयोगकर्ताओं को खोजें जो दोनों नियमों को पूरा करते हैं:

 var specification = new CreatedAfter(new DateTime(2019, 1, 1).Combine(new CreatedBefore(new DateTime(2020, 1, 1)); var users = repository.List(specification); 

कंबाइन विधि के साथ संयोजन मनमाने नियमों का समर्थन करता है। मुख्य बात यह है कि बाईं ओर का परिणामी प्रकार दाएं पक्ष के इनपुट प्रकार के साथ मेल खाता है। इस प्रकार, आप अनुमानों के नियमों का निर्माण कर सकते हैं, पृष्ठांकन के लिए छोड़ें / ले सकते हैं, नियमों को छांट सकते हैं, लाने के लिए, आदि।

या नियम अधिक प्रतिबंधक है - यह केवल उन श्रृंखलाओं का समर्थन करता है जिनमें फ़िल्टरिंग की स्थिति होती है। एक उदाहरण के उपयोग पर विचार करें: हमें २००० से पहले या २०२० के बाद बनाए गए सभी पात्र मिलते हैं:

 var specification = new CreatedAfter(new DateTime(2020, 1, 1).Or(new CreatedBefore(new DateTime(2000, 1, 1)); var users = repository.List(specification ); 

IQuery इंटरफ़ेस काफी हद तक IQueryable इंटरफ़ेस को दोहराता है, इसलिए इसमें कोई विशेष प्रश्न नहीं होने चाहिए। हमें केवल विशिष्ट तरीकों पर ध्यान दें:

Fetch / ThenFetch - आपको अनुकूलन उद्देश्यों के लिए उत्पन्न क्वेरी में संबंधित डेटा शामिल करने की अनुमति देता है। बेशक, यह थोड़ा टेढ़ा है जब हमारे पास बुनियादी ढांचे के कार्यान्वयन की विशेषताएं हैं जो व्यावसायिक नियमों को प्रभावित करती हैं, लेकिन, जैसा कि मैंने कहा, वास्तविकता कठोर और शुद्ध सार है - यह एक बल्कि सैद्धांतिक चीज है।

जहां - IQuery इस विधि के दो अधिभार की घोषणा करता है, एक अभिव्यक्ति के रूप में फ़िल्टर करने के लिए सिर्फ एक लंबोदर अभिव्यक्ति लेता है <Func <T, bool >> , और दूसरा अतिरिक्त पैरामीटर IQueryContext में भी लेता है, जो आपको नेस्टेड उपश्रेणियों को निष्पादित करने की अनुमति देता है। आइए एक उदाहरण देखें।

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

 public class CharactersForUserWithEmailDomain: Specification<ReadCharacter> { public CharactersForUserWithEmailDomain(string domain) { var usersQuery = Source<User>(x => x.Email.Contains(domain)).Projection(x => x.Id); Query = Source().Where((x, ctx) => ctx.GetQueryResult<int>(usersQuery).Contains(x.Id)); } } 

निष्पादन के परिणामस्वरूप, निम्नलिखित sql क्वेरी उत्पन्न होगी:

 select readcharac0_.id as id1_3_, readcharac0_.UserId as userid2_3_, readcharac0_.Name as name3_3_ from ReadCharacters readcharac0_ where readcharac0_.UserId in ( select user1_.Id from Users user1_ where user1_.Email like ('%'+@p0+'%') ); @p0 = '@inmagna.ca' [Type: String (4000:0:0)] 

इन सभी अद्भुत नियमों को पूरा करने के लिए, IRepository इंटरफ़ेस परिभाषित किया गया है , जो आपको पहचानकर्ता द्वारा आइटम प्राप्त करने की अनुमति देता है, विनिर्देशन के अनुसार एक (पहली उपयुक्त) या वस्तुओं की सूची प्राप्त करता है, और रिपॉजिटरी से आइटमों को सहेजता और हटाता भी है।
प्रश्नों की परिभाषा के साथ, हमें पता चला, अब यह समझने के लिए हमारे ORM को पढ़ाना बाकी है।
ऐसा करने के लिए, हम Singularis.Infrastructure.NHibernate (ef.core के लिए सब कुछ समान दिखता है, केवल ef.core की बारीकियों के साथ) की असेंबली का विश्लेषण करेंगे।

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

मुख्य जादू और सबसे बदसूरत कोड IQuery को IQueryable - SpecificationExecutor में परिवर्तित करने के लिए जिम्मेदार वर्ग में निहित है। इस वर्ग में बहुत अधिक प्रतिबिंब होते हैं, जो एक विशिष्ट ORM (EiberFetchingExtensionsMethods for NHiberante) के क्वेरी करने योग्य तरीकों या विस्तार विधियों को कहते हैं।

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

वर्णित समाधान का उपयोग करने के लायक कब है? "जब नहीं होना चाहिए" सवाल से शुरू करना शायद आसान है:

• highload - यदि आपको उच्च प्रदर्शन की आवश्यकता है, तो ORM का उपयोग स्वयं एक प्रश्न उठाता है। हालांकि, निश्चित रूप से, कोई भी एक निष्पादक को लागू करने से मना नहीं करता है जो एसक्यूएल में प्रश्नों का अनुवाद करेगा और उन्हें निष्पादित करेगा ...
• बहुत छोटी परियोजनाएं - यह बहुत व्यक्तिपरक है, लेकिन, आपको यह स्वीकार करना होगा कि ORM और पूरे साथ के चिड़ियाघर को "टूडू लिस्ट" परियोजना में खींचकर, एक तोप से गौरैया की शूटिंग की तरह दिखता है।

किसी भी मामले में, जिसने अंत तक पढ़ने में महारत हासिल की - अपने समय के लिए धन्यवाद। मैं भविष्य के विकास के लिए प्रतिक्रिया की उम्मीद करता हूं!

मैं लगभग भूल गया - प्रोजेक्ट कोड GitHub'e - https://github.com/SingularisLab/singularis.specification पर उपलब्ध है