लोग पुरानी पुस्तकों से वास्तुकला सीखते हैं जो जावा के लिए लिखी गई थीं। किताबें अच्छी हैं, लेकिन वे उस समय के उपकरणों के साथ उस समय की समस्याओं का समाधान प्रदान करते हैं। समय बदल गया है, सी # जावा की तुलना में प्रकाश स्काला के समान है, और कुछ नई अच्छी किताबें हैं।

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

यह लेख DotNext 2018 मास्को सम्मेलन से मेरी रिपोर्ट का एक प्रतिलेख है। पाठ के अलावा, कट के नीचे स्लाइड के लिए एक वीडियो और एक लिंक है।

साइट पर स्लाइड और रिपोर्ट पृष्ठ ।

मेरे बारे में संक्षेप में: मैं कज़ान से हूं, मैं हाई टेक ग्रुप के लिए काम करता हूं। हम व्यापार के लिए सॉफ्टवेयर विकसित कर रहे हैं। हाल ही में, मैं कज़ान संघीय विश्वविद्यालय में कॉर्पोरेट सॉफ्टवेयर डेवलपमेंट नामक पाठ्यक्रम पढ़ा रहा हूं। समय-समय पर मैं अभी भी हैबर पर इंजीनियरिंग प्रथाओं के बारे में, उद्यम सॉफ्टवेयर के विकास के बारे में लेख लिखता हूं।

जैसा कि आप शायद अनुमान लगा चुके हैं, आज मैं उद्यम सॉफ्टवेयर के विकास के बारे में बात करूंगा, अर्थात्, आधुनिक वेब अनुप्रयोगों की संरचना कैसे करें:

• मानदंड
• स्थापत्य विचार के विकास का एक संक्षिप्त इतिहास (क्या था, क्या बन गया है, क्या समस्याएं हैं);
• क्लासिक पफ वास्तुकला की खामियों का अवलोकन
• निर्णय
• विवरण में गोताखोरी के बिना कार्यान्वयन के चरण-दर-चरण विश्लेषण
• परिणाम है।

मापदंड

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



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

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

वास्तुकला का विकास

एक बार, जब प्रोग्रामर सिर्फ प्रोग्राम लिखना शुरू कर रहे थे, तब भी कोई आर्किटेक्चर नहीं था, और हर कोई हर चीज को पसंद करता था।



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



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



अगला चरण तथाकथित प्याज वास्तुकला था । ऐसा लगता है कि एक बहुत बड़ा अंतर है: इससे पहले एक छोटा वर्ग था, और यहां सर्कल थे। यह पूरी तरह से अलग लगता है।



वास्तव में नहीं। संपूर्ण अंतर यह है कि इस समय के आसपास कहीं ना कहीं SOLID के सिद्धांत तैयार किए गए थे, और यह पता चला कि क्लासिक प्याज में निर्भरता के उलट होने की समस्या है, क्योंकि किसी कारण से अमूर्त डोमेन कोड कार्यान्वयन पर निर्भर करता है, डेटा एक्सेस पर, इसलिए हमने डेटा एक्सेस को तैनात करने का निर्णय लिया। , और डेटा एक्सेस डोमेन पर निर्भर है।



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

एक सरल उदाहरण। ईमेल अपडेट

आइए देखें कि इस तरह के प्रतिमान में एक साधारण उपयोग मामला कैसा दिखेगा - उपयोगकर्ता के ईमेल पते को अपडेट करना।



हमें एक अनुरोध भेजने, सत्यापन करने, डेटाबेस में मूल्य को अपडेट करने, एक नए ईमेल पर एक अधिसूचना भेजने की आवश्यकता है: "सब कुछ क्रम में है, आपने अपना ईमेल बदल दिया है, हम जानते हैं कि सब कुछ ठीक है", और "200" ब्राउज़र को जवाब दें - सब कुछ ठीक है।



कोड कुछ इस तरह दिख सकता है। यहां हमारे पास मानक ASP.NET MVC सत्यापन है, डेटा पढ़ने और अपडेट करने के लिए ORM है, और कुछ प्रकार का ईमेल-प्रेषक है जो एक अधिसूचना भेजता है। ऐसा लगता है कि सब कुछ अच्छा है, है ना? एक चेतावनी - एक आदर्श दुनिया में।

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



"सेवाएं कहां हैं?" - आप कहते हैं। मैंने नियंत्रकों को सभी तर्क लिखे। बेशक, यह एक समस्या है, अब मैं सेवाओं को जोड़ दूंगा, और सबकुछ ठीक हो जाएगा।



हम सेवाओं को जोड़ते हैं, और यह वास्तव में बेहतर हो जाता है, क्योंकि एक बड़े फुटक्लॉथ के बजाय, हमें एक छोटी सी सुंदर रेखा मिली।

क्या यह बेहतर हो गया है? बन गया है! और अब हम विभिन्न नियंत्रकों में इस विधि का पुन: उपयोग कर सकते हैं। परिणाम स्पष्ट है। आइए इस पद्धति के कार्यान्वयन को देखें।



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



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



और यह विचार एक से अधिक लोगों के लिए हुआ। यदि आप गूगल करते हैं, तो कम से कम तीन सम्माननीय पति एक ही बात के बारे में लिखते हैं। ऊपर से नीचे तक: स्टीफन .NET जंकी (दुर्भाग्य से, मैं उसका अंतिम नाम नहीं जानता, क्योंकि वह इंटरनेट पर कहीं भी प्रकट नहीं होता है), साधारण इंजेक्टर आईओसी कंटेनर के लेखक। अगला जिम्मी बोगार्ड ऑटोमैपर का लेखक है। और नीचे मज़ा और लाभ के लिए स्कॉट # Vlashin, F # के लेखक हैं।



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



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



आरंभ करने के लिए, उपयोगकर्ता सेवा से छुटकारा पाएं। हम विधि निकालते हैं और एक वर्ग बनाते हैं। और हम इसे हटा देंगे, और हम इसे फिर से निकाल देंगे। और फिर क्लास लें और निकालें।



आइए विचार करें, क्या ये कक्षाएं समकक्ष हैं या नहीं? GetUser वर्ग डेटा लौटाता है और सर्वर पर कुछ भी नहीं बदलता है। यह, उदाहरण के लिए, "मुझे उपयोगकर्ता आईडी दें" अनुरोध के बारे में। UpdateEmail और BanUser कक्षाएं ऑपरेशन का परिणाम लौटाती हैं और राज्य को बदल देती हैं। उदाहरण के लिए, जब हम सर्वर को बताते हैं: "कृपया राज्य को बदलें, आपको कुछ बदलने की आवश्यकता है।"



आइए HTTP प्रोटोकॉल को देखें। एक GET विधि है, जो HTTP प्रोटोकॉल के विनिर्देश के अनुसार, डेटा को वापस करना चाहिए और सर्वर की स्थिति को नहीं बदलना चाहिए।



और अन्य तरीके हैं जो सर्वर की स्थिति को बदल सकते हैं और ऑपरेशन के परिणाम को वापस कर सकते हैं।



CQRS प्रतिमान विशेष रूप से HTTP प्रोटोकॉल के लिए डिज़ाइन किया गया लगता है। क्वेरी GET ऑपरेशन्स हैं, और कमांड PUT, POST, DELETE हैं - कुछ भी आविष्कार करने की आवश्यकता नहीं है।



हम अपने हैंडलर को फिर से परिभाषित करते हैं और अतिरिक्त इंटरफेस को परिभाषित करते हैं। IQueryHandler, जो केवल इस बात में भिन्न है कि हमने बाधा डाली कि इनपुट मानों का प्रकार IQuery है। IQuery एक मार्कर इंटरफ़ेस है, इसमें कुछ भी नहीं है लेकिन यह सामान्य है। हमें QueryHandler में बाधा डालने के लिए जेनेरिक की आवश्यकता है, और अब, QueryHandler की घोषणा करते हुए, हम वहां Query नहीं पारित कर सकते हैं, लेकिन Query ऑब्जेक्ट को पास करते हुए, हम उसका रिटर्न वैल्यू जानते हैं। यह सुविधाजनक है यदि आपके पास केवल एक इंटरफ़ेस है, तो आपको कोड में उनके कार्यान्वयन के लिए देखने की ज़रूरत नहीं है, और फिर से ताकि गड़बड़ न हो। आप IQueryHandler लिखते हैं, वहां एक कार्यान्वयन लिखते हैं, और TOut में आप दूसरे प्रकार के रिटर्न वैल्यू का विकल्प नहीं दे सकते। यह सिर्फ संकलन नहीं है। इस प्रकार, आप तुरंत देख सकते हैं कि कौन से इनपुट मान किस इनपुट डेटा के अनुरूप हैं।



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

हैंडलर कार्यान्वयन

हैंडलर, हमने घोषणा की, उनका कार्यान्वयन क्या है?



कोई समस्या है, हाँ? लगता है कुछ फेल हो गया।

डेकोरेटर बचाव के लिए दौड़ पड़े

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



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



अब सज्जाकारों की मदद से आप एक पूरी पाइपलाइन का निर्माण कर सकते हैं। टीमों के साथ शुरू करते हैं। हमारे पास क्या था? इनपुट मान, सत्यापन, एक्सेस अधिकारों का सत्यापन, तर्क स्वयं, इस तर्क के परिणामस्वरूप होने वाली कुछ घटनाएं, और मान लौटाते हैं।



आइए सत्यापन के साथ शुरू करते हैं। हम एक डेकोरेटर की घोषणा करते हैं। टाइप टी सत्यापनकर्ताओं से IEnumerable इस डेकोरेटर के कंस्ट्रक्टर में आता है। हम उन सभी को निष्पादित करते हैं, जांचते हैं कि क्या सत्यापन विफल रहता है और वापसी प्रकार IEnumerable<validationresult> , तो हम इसे वापस कर सकते हैं क्योंकि प्रकार मिलान करते हैं। और अगर यह कुछ अन्य हैंडर है, तो ठीक है, तो आपको एक अपवाद फेंकना होगा, क्योंकि यहां कोई परिणाम नहीं है, एक और रिटर्न मान का प्रकार।



अगला चरण सुरक्षा है। हम डेकोरेटर की भी घोषणा करते हैं, चेकपर्मिशन विधि बनाते हैं, और सत्यापित करते हैं। अगर अचानक कुछ गलत हो गया, तो सब कुछ, हम जारी नहीं रखते हैं। अब, जब हमने सभी जाँच पूरी कर ली हैं और सुनिश्चित हैं कि सब कुछ ठीक है, हम अपने तर्क को पूरा कर सकते हैं।

आदिम के साथ जुनून

तर्क के कार्यान्वयन को दिखाने से पहले, मैं थोड़े पहले शुरू करना चाहता हूं, अर्थात् इनपुट मान जो वहां आते हैं।



अब, यदि हम ऐसे वर्ग को बाहर करते हैं, तो सबसे अधिक बार ऐसा कुछ दिखाई दे सकता है। कम से कम कोड जो मैं रोजमर्रा के काम में देखता हूं।



कार्य करने के लिए सत्यापन के लिए, हम यहां कुछ विशेषताएँ जोड़ते हैं जो आपको बताते हैं कि यह किस प्रकार का सत्यापन है। यह डेटा संरचना के दृष्टिकोण से मदद करेगा, लेकिन डेटाबेस में मानों की जाँच जैसे सत्यापन के साथ मदद नहीं करेगा। यह सिर्फ EmailAddress है, यह स्पष्ट नहीं है कि, डेटाबेस में जाने के लिए इन विशेषताओं का उपयोग कैसे करें, कहाँ जाँचें। विशेषताओं के बजाय, आप विशेष प्रकार पर जा सकते हैं, फिर यह समस्या हल हो जाएगी।



int आदिम के बजाय, हम एक Id प्रकार की घोषणा करते हैं जिसमें एक जेनेरिक होता है कि यह एक निश्चित कुंजी के साथ एक निश्चित इकाई है। और हम या तो इस इकाई को कंस्ट्रक्टर के पास भेज देते हैं, या इसकी आईडी को पास कर देते हैं, लेकिन साथ ही हमें एक फंक्शन पास करना होगा, जिससे कि Id ले और वापस आ सके, यह देख सकता है कि यह वहाँ शून्य है या नहीं।



हम ईमेल के साथ भी ऐसा ही करते हैं। सभी ईमेल को नीचे पंक्ति में कनवर्ट करें ताकि सब कुछ हमारे लिए समान दिखाई दे। अगला, हम ईमेल विशेषता लेते हैं, इसे ASP.NET सत्यापन के साथ संगतता के लिए स्थिर घोषित करते हैं, और यहाँ हम इसे बस कहते हैं। यानी यह भी किया जा सकता है। ASP.NET अवसंरचना के लिए यह सब पकड़ने के लिए, आपको क्रमांकन और / या मॉडलबाइंडिंग को थोड़ा संशोधित करना होगा। वहाँ बहुत कोड नहीं है, यह अपेक्षाकृत सरल है, इसलिए मैं वहाँ नहीं रुकता।



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



अगला बिंदु मैं इस पर ध्यान देना चाहूंगा कि वर्ग में आक्रमणकारियों की स्थिति है, क्योंकि अक्सर एक एनीमिक मॉडल का उपयोग किया जाता है, जिसमें बस एक वर्ग, कई गेट्टर-सेटर होते हैं, यह पूरी तरह से अस्पष्ट है कि उन्हें एक साथ कैसे काम करना चाहिए। हम जटिल व्यावसायिक तर्क के साथ काम करते हैं, इसलिए हमारे लिए यह महत्वपूर्ण है कि कोड स्व-दस्तावेजीकरण हो। इसके बजाय, ORM के लिए खाली के साथ असली कंस्ट्रक्टर घोषित करना बेहतर है, इसे संरक्षित घोषित किया जा सकता है ताकि प्रोग्रामर अपने आवेदन कोड में इसे कॉल न कर सकें, और ORM नहीं कर सके। यहां हम आदिम प्रकार नहीं, बल्कि ईमेल प्रकार पास करते हैं, यह पहले से ही सही ढंग से सही है, अगर यह शून्य है, तो हम अभी भी एक अपवाद फेंकते हैं। आप कुछ Fody, PostSharp का उपयोग कर सकते हैं, लेकिन C # 8 जल्द ही आने वाला है। तदनुसार, एक गैर-अशक्त संदर्भ प्रकार होगा, और भाषा में इसके समर्थन की प्रतीक्षा करना बेहतर है। अगले क्षण, यदि हम नाम और उपनाम बदलना चाहते हैं, तो सबसे अधिक संभावना है कि हम उन्हें एक साथ बदलना चाहते हैं, इसलिए एक उपयुक्त सार्वजनिक तरीका होना चाहिए जो उन्हें एक साथ बदलता है।



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



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



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



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

हैंडलर

इन सभी बदलावों के बाद, हैण्डर यहाँ कैसा दिखेगा?



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

घटनाक्रम

डोमेन घटनाएँ।



संभवतः पहली बार इस अवधारणा को उदी दहन ने अपने पोस्ट "डोमेन इवेंट्स - साल्वेशन" में लोकप्रिय किया था। वहाँ, वह सुझाव देता है कि केवल एक स्टैटिक क्लास बढ़ाएँ और इस तरह की घटनाओं को फेंकने की घोषणा करें। थोड़ी देर बाद, जिमी बोगार्ड ने एक बेहतर कार्यान्वयन का प्रस्ताव दिया, इसे "एक बेहतर डोमेन ईवेंट पैटर्न" कहा जाता है।



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



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

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



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

लॉगिंग और प्रोफाइलिंग

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

प्रतिक्रिया

पूरी पाइपलाइन के काम करने के बाद, हम केवल Dto को ले सकते हैं और इसे आगे ब्राउज़र में भेज सकते हैं, JSON को सीरीज़ कर सकते हैं।



लेकिन एक और छोटी सी बात, ऐसी बात जो कभी-कभी भुला दी जाती है: हर स्तर पर, एक अपवाद यहां हो सकता है, और वास्तव में आपको किसी तरह से उनकी जरूरत है।



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



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



सार्वजनिक रूप से यह घोषित करने के बजाय कि कोई व्यक्ति कोड में अशक्तता के लिए जाँच नहीं कर सकता है, पैटर्न मिलान का उपयोग किया जाता है। फिर से, F # में यह बिल्ट-इन पैटर्न मैचिंग लैंग्वेज होगी, C # में हमें एक अलग मेथड लिखना होगा, जिसमें हम एक फंक्शन पास करेंगे, जो यह जानता है कि ऑपरेशन के सफल रिजल्ट के साथ क्या करना है, कैसे इसे चेन के नीचे बदलना है, और एक एरर के साथ। अर्थात्, हमारे लिए कोई भी शाखा काम नहीं करती है, हमें इसे एक ही लौटाया हुआ परिणाम देना चाहिए। एफ # में, यह सब बहुत अच्छी तरह से काम करता है, क्योंकि एक कार्यात्मक रचना है, अच्छी तरह से, और बाकी सब कुछ जो मैंने पहले ही सूचीबद्ध किया है। .NET में, यह थोड़ा खराब काम करता है, क्योंकि जैसे ही आपके पास एक से अधिक परिणाम होते हैं, लेकिन बहुत कुछ - और लगभग हर विधि एक कारण या किसी अन्य के लिए विफल हो सकती है - लगभग सभी परिणामी फ़ंक्शन प्रकार परिणाम प्रकार बन जाते हैं, और आपको उनकी आवश्यकता है किसी चीज को मिलाना।



उन्हें संयोजित करने का सबसे आसान तरीका LINQ का उपयोग करना है , क्योंकि वास्तव में LINQ न केवल IEnumerable के साथ काम करता है, यदि आप SelectMany और Select Methods को सही तरीके से पुनर्परिभाषित करते हैं, तो C # कंपाइलर देखेंगे कि आप इन प्रकारों के लिए LINQ सिंटैक्स का उपयोग कर सकते हैं। सामान्य तौर पर, यह हास्केल डू-नोटेशन के साथ या एफ # में एक ही कम्प्यूटेशन एक्सप्रेशंस के साथ ट्रेसिंग पेपर निकलता है। इसे कैसे पढ़ा जाना चाहिए? यहां हमारे पास ऑपरेशन के तीन परिणाम हैं, और यदि तीनों मामलों में सब कुछ ठीक है, तो इन परिणामों को r1 + r2 + r3 लें और इसे जोड़ें। परिणामी मूल्य का प्रकार भी परिणाम होगा, लेकिन नया परिणाम, जिसे हम चयन में घोषित करते हैं। सामान्य तौर पर, यह एक कामकाजी दृष्टिकोण भी है, अगर एक नहीं बल्कि।



अन्य सभी डेवलपर्स के लिए, जैसे ही आप C # में इस तरह का कोड लिखना शुरू करते हैं, आप कुछ इस तरह दिखने लगते हैं। “ये बुरे डरावने अपवाद हैं, इन्हें मत लिखो! वे दुष्ट हैं! बेहतर कोड लिखें जो कोई भी नहीं समझता है और डिबग नहीं कर सकता है! "



सी # एफ # नहीं है, यह कुछ अलग है, इसके आधार पर कोई अलग अवधारणाएं नहीं हैं, और जब हम ग्लोब पर एक उल्लू को खींचने की कोशिश करते हैं, तो यह हल्का, असामान्य होता है।



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



हम जानते हैं कि यदि सत्यापन में कोई समस्या है, तो आपको कोड 400 या 422 (अनप्रोसेबल एंटिटी) को वापस करना होगा। यदि प्रमाणीकरण और प्राधिकरण के साथ कोई समस्या है, तो 401 और 403 हैं। यदि कुछ गलत हुआ, तो कुछ गलत हुआ। और अगर कुछ गलत हो गया है और आप उपयोगकर्ता को वास्तव में क्या बताना चाहते हैं, तो अपने अपवाद प्रकार को परिभाषित करें, यह कहें कि यह IHasUserMessage है, इस इंटरफ़ेस में एक संदेश प्राप्तकर्ता घोषित करें और बस जांचें: यदि यह इंटरफ़ेस लागू किया गया है, तो आप एक संदेश ले सकते हैं अपवाद से और इसे JSON में उपयोगकर्ता के पास भेज दें। यदि यह इंटरफ़ेस लागू नहीं किया गया है, तो इसका मतलब है कि किसी प्रकार की सिस्टम त्रुटि है, और हम केवल उपयोगकर्ताओं को बताते हैं कि कुछ गलत हुआ था, हम पहले से ही कर रहे हैं, हम सभी जानते हैं - ठीक है, हमेशा की तरह।

क्वेरी पाइपलाइन

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

सुरक्षा

आइए सुरक्षा जांच में बेहतर देखें। एक ही सुरक्षा डेकोरेटर भी हो सकता है, जो यह जाँच करता है कि यह अनुरोध किया जा सकता है या नहीं:



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

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



ORM अंतर्निहित टूल के साथ ऐसा क्यों नहीं करते हैं, उदाहरण के लिए, एक इकाई ढांचे में ग्लोबल फिल्टर? फिर, अपने लिए कोई चक्रीय निर्भरता न बनाने और संदर्भ में अपनी व्यावसायिक परत के बारे में कोई अतिरिक्त कहानी नहीं खींचने के लिए।

क्वेरी पाइपलाइन। मॉडल पढ़ें

यह पढ़ने के मॉडल को देखने के लिए बनी हुई है। CQRS प्रतिमान रीडिंग स्टैक में डोमेन मॉडल का उपयोग नहीं करता है, इसके बजाय, हम तुरंत उस Dto का निर्माण करते हैं जो ब्राउज़र को फिलहाल चाहिए।



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



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

फिर हम ब्राउज़र में फ़िल्टरिंग, सॉर्टिंग और यह सब प्रदर्शित करते हैं। , DotNext, , , , , , expression' , .

SQL

. , DotNext', — SQL. Select , , , queryable- .



, . , Title, Title , . , . SubTitle, , , - , queryable- . , .

, . , , . , , . «JsonIgnore», . , , Dto. , , . JSON, , Created LastUpdated , SubTitle — , . , , , , , . , - .



. , -, , . , pipeline, . — , , . , SaveChanges, Query SaveChanges. , , , NuGet, .

. , - , , . , , , , , — . , , : « », — . .

, ?



- . .



, , , . MediatR , . , , — , MediatR pipeline behaviour. , Request/Response, RequestHandler' . Simple Injector, — .



, , , , TIn: ICommand.



Simple Injector' constraint' . , , , constraint', Handler', constraint. , constraint ICommand, SaveChanges constraint' ICommand, Simple Injector , constraint' , Handler'. , , , .

? Simple Injector MeriatR — , , Autofac', -, , , . , .

,

, «».



, «Clean architecture». .



- - , MVC, , .



, , , Angular, , , , . , : « — MVC-», : « Features, : , Blog - Import, - ».

, , , , MVC-, , - , . MVC . , , — . .





- , - -, .

-, , . , . , - , User Service, pull request', , User Service , . , - , - , . - , .

. , . , , , . , , , , , , , - . , ( , ), , «Delete»: , , . .

— «», , , , . , : , , , . , . , , . , , .

: . « », : , , . , , , , , , , . , . , - pull request , — , — - , . VCS : - , ? , - , , .



, , , . : . , . , , , , . , , , . , , . « », , . , , — , , .

: , - , . . - , , , , . - , - , , , , . .



. , IHandler . .

IHandler ICommandHandler IQueryHandler , . , , . , CommandHandler, CommandHandler', .

ऐसा क्यों? , Query , Query — . , , , Hander, CommandHandler QueryHandler, - use case, .

— , , , , : , .

, . , . , -.

C# 8, nullable reference type . , , , , .

ChangeTracker' ORM.

Exception' — , F#, C#. , - , - , . , , Exception', , LINQ, , , , , , Dapper - , , , .NET.

, LINQ, , permission' — . , , - , , . , — .

. :

---

• Vertical Slices
  
  • www.youtube.com/watch?v=SUiWfhAhgQw
  • www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91
  • cuttingedge.it/blogs/steven/pivot/entry.php?id=92
• 
  
  • habr.com/post/266937
  • habr.com/post/205088
  • habr.com/post/205108
• Domain Events
  
  • udidahan.com/2009/06/14/domain-events-salvation
  • lostechies.com/jimmybogard/2014/05/13/a-better-domain-events-pattern
  • enterprisecraftsmanship.com/2017/10/03/domain-events-simple-and-reliable-solution
• DDD
  
  • habr.com/post/334126
• ROP
  
  • fsharpforfunandprofit.com/rop
  • habr.com/post/339606
  • habr.com/post/347284
• LINQ Expressions:
  
  • habr.com/company/jugru/blog/423891
• Clean Architecture
  
  • www.youtube.com/watch?v=JEeEic-c0D4

— . . — «Domain Modeling Made Functional», F#, F#, , , , , . C# , , Exception'.

, , — «Entity Framework Core In Action». , Entity Framework, , DDD ORM, , ORM DDD .

विज्ञापन का मिनट। 15-16 2019 .NET- DotNext Piter, . , .