8

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

वर्तमान में मेरा बुनियादी ढांचा का पहला संस्करण तैयार है और अच्छी तरह से काम कर रहा है। लेकिन मैं अगले संस्करण में बाध्य संदर्भ संरचना को कार्यान्वित करना चाहता हूं।

मैंने निम्नलिखित स्थिति को समझाने की कोशिश की।

डीबीकोर: डेटा संचालन के लिए ज़िम्मेदार है। इकाई फ्रेमवर्क 5 कोड पहले इस्तेमाल किया। इसमें केवल एक डीबीकॉन्टेक्स्ट क्लास और सभी डीबीसेट्स परिभाषित हैं। निम्नलिखित इंटरफेस के आधार पर जेनेरिक रिपोजिटरी पैटर्न और वर्क पैटर्न का यूनिट भी लागू किया गया।

IGenericRepository

public interface IGenericRepository<TEntity> 
    where TEntity : class { 
     void Delete(object id); 
     void Delete(TEntity entityToDelete); 
     System.Collections.Generic.IEnumerable<TEntity> Get(System.Linq.Expressions.Expression<Func<TEntity, bool>> filter = null, Func<System.Linq.IQueryable<TEntity>, System.Linq.IOrderedQueryable<TEntity>> orderBy = null, string includeProperties = ""); 
     System.Collections.Generic.IEnumerable<TEntity> GetAll(); 
     TEntity GetByID(object id); 
     System.Collections.Generic.IEnumerable<TEntity> GetWithRawSql(string query, params object[] parameters); 
     void Insert(TEntity entity); 
     void Update(TEntity entityToUpdate); 
    } 

IUnitOfWork

public interface IUnitOfWork { 
     void Dispose(); 
     IGenericRepository<Test> TestRepository { 
      get; 
     } 
     IGenericRepository<Log> LogRepository { 
      get; 
     } 
     void Save(); 
    } 

मॉडल: DbCore और इकाई की रूपरेखा के लिए जिम्मेदार भंडारण इकाई मॉडल डोमेन: का प्रतिनिधित्व करते हैं व्यापार तर्क परत भी के लिए DTOs संग्रहीत करता है सत्ता ऑब्जेक्ट्स जो मॉडल प्रोजेक्ट में संग्रहीत हैं। वर्तमान में व्यापार तर्क है कि इंटरफ़ेस IService

public interface IService<TEntity> { 

     IEnumerable<TEntity> Get(); 
     TEntity GetByID(int id); 
     void Insert(TEntity entity); 
    } 

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

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

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

एपीआई: एएसपी.नेट एमवीसी वेब एपीआई परियोजना सेवा परत का प्रतिनिधित्व करती है। डोमेन परत का उपभोग करता है और ग्राहकों को सेवा देता है। नियंत्रकों को ctor पैरामीटर के रूप में IService इंटरफ़ेस मिलता है और डोमेन परत के माध्यम से डेटा परत तक पहुंचने के लिए इसका उपयोग करता है।

वेब: एएसपी.NET एमवीसी 4 आधारित वेब प्रोजेक्ट, जो उपयोगकर्ता के साथ बातचीत के साथ जिम्मेदार है। डेटा तक पहुंचने के लिए एपीआई विधियों का उपभोग करता है। सभी नियंत्रकों को IConsumeRepository नामक एक इंटरफ़ेस मिलता है जो एपीआई को एचटीपी क्लाइंट के माध्यम से जोड़ता है।

public interface IConsumeRepository<TEntity> { 
     Task<TEntity> Create(TEntity TestInfo); 
     Task Delete(int id);  
     Task<IEnumerable<TEntity>> Get(); 
     Task<TEntity> Get(int id); 
     TEntity New();  
     Task<TEntity> Update(TEntity TestInfo, int entityId); 
    } 

ऑटोफैक सभी परियोजनाओं के लिए आईओसी और डी के लिए प्रतिपूर्ति योग्य है।

अब यह मेरा वर्तमान आधारभूत संरचना है, मुझे लगता है कि मैंने मूल्यांकन करने की आवश्यकता वाले सभी चीजों को समझाया।

अब मैं निम्नलिखित बातें पता लगाना करने के लिए कोशिश कर रहा हूँ,

प्रश्न 1: वहाँ कुछ भी नहीं जिस तरह से मैं इस्तेमाल किया impelemented किया जाना चाहिए है?

प्रश्न 2: बाउंड किए गए संदर्भों को लागू करने के लिए सबसे अच्छा तरीका क्या है? मैंने हाल ही में जूली लर्मन के वीडियो देखे और नमूने परियोजनाओं की समीक्षा की। आम बात यह है कि मैंने बीबी को डीबीकॉन्टेक्स्ट से प्राप्त किया। लेकिन मैं निश्चित नहीं हो सका। क्योंकि मैंने सोचा था कि बीसी डोमेन (व्यापार तर्क) परत में होना चाहिए डीबीकोर (डेटा एक्सेस) परत में नहीं।

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

यह एक लंबा सवाल बन गया लेकिन यदि आप बेहतर विचारधारा बनाने के लिए अपने विचार साझा करते हैं तो मैं बहुत खुश हूं।

उत्तर

30

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

प्रश्न 2: आपके पास कितने अलग डोमेन मॉडल (विभिन्न सर्वव्यापी भाषाओं के साथ) हैं? एक? दो? तीन? प्रत्येक मॉडल के लिए, इसे जितना संभव हो सके अन्य मॉडलों और आधारभूत संरचना चिंताओं से अलग करें।

एरिक इवांस मुख्य रूप से एक भाषाई सीमा (अपनी पुस्तक से उद्धरण) के रूप में एक घिरे संदर्भ परिभाषित करता है:

एक घिरा संदर्भ एक विशेष मॉडल की प्रयोज्यता delimits तो कि टीम के सदस्यों के लिए एक स्पष्ट है और क्या है और यह अन्य CONTEXTS से कैसे संबंधित है की साझा समझ है। उस CONTEXT के भीतर, मॉडल को तार्किक रूप से एकीकृत रखने के लिए काम करें, लेकिन उन सीमाओं के बाहर प्रयोज्यता के बारे में चिंता न करें। अन्य CONTEXTS में, अन्य मॉडल, शब्दावली में अंतर, अवधारणाओं और नियमों में और उबाऊ भाषा के बोलियों में लागू होते हैं।

DBContext सही दिशा में इशारा कर सकता है, लेकिन याद रखें कि यह एक बुनियादी ढांचे विरूपण साक्ष्य है, नहीं एक डोमेन अवधारणा। यह "यूनिट-ऑफ-वर्क और रिपोजिटरी पैटर्न के संयोजन का प्रतिनिधित्व करता है और आपको एक डेटाबेस से क्वेरी करने और समूह को एक साथ बदलने में सक्षम बनाता है जिसे फिर यूनिट के रूप में स्टोर में लिखा जाएगा।" _ (MSDN Docs से)।

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

प्रश्न 3: डीटीओ एक एपीआई के लिए संदर्भ सीमा को लागू करने का एक अच्छा तरीका हो सकता है। एपीआई फिर अन्य मॉडलों के लिए एक भ्रष्टाचार विरोधी विरोधी परत के रूप में काम कर सकते हैं। यूआई के लिए आम तौर पर उनका उपयोग करने का कारण डोमेन मॉडल में यूआई अवधारणाओं को खून से बचना है।

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

+8

कुछ सौ बार यहां +1 क्लिक करने में सक्षम होना चाहते हैं! –