मुझे कौन सी परत चाहिए .edmx और उत्पन्न पॉको कक्षाएं?

Question

यह ईएफ डीबी प्रथम मॉडल के साथ एक स्तरित डिजाइन के बारे में है।

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

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

मैंने यहां पुराने सरल डिजाइन का पुन: उपयोग करने का विचार किया। लेकिन यह सुनिश्चित नहीं है कि मुझे/कौन सी परत को एडीएमएक्स फ़ाइल और जेनरेट किए गए पॉको कक्षाओं में बिल्कुल फिट होना चाहिए। मुझे स्तरित आर्किटेक्चर शैली डीबीफ़र्स्ट दृष्टिकोण का उपयोग करने वाले किसी भी नमूने नहीं मिला।

मैंने इसका उल्लेख किया। http://aspnetdesignpatterns.codeplex.com लेकिन वे NHybernate

का उपयोग पुराने डिजाइन का उच्चतम अवलोकन है।

डिज़ाइन/नमूने पर कोई सुझाव, कृपया आपका स्वागत है।

संपादित करें:

नीचे जवाब से, मुझे लगता है कि इकाई की रूपरेखा Pocos हम मौजूदा संस्थाओं/डोमेन परत करने के लिए डोमेन परत और वहाँ उत्पन्न POCO कक्षाएं लगाने का नाम बदलने सकता है पैदा करता है। साथ ही हम डेटाएक्सेलेयर में .edmx को आईआरपीओएसटीरी कक्षाओं की सूची के साथ रख सकते हैं जो टीडीडी के लिए ईएफ लपेटता है। क्या यह संवेदना करता है? या कोई मूल्यवान अंक?

अद्यतन:

वर्तमान में मैं DataAccessLayer हटा दिया और केवल संस्थाओं परत जो एक model.edmx फ़ाइल और एफई द्वारा उत्पन्न वर्गों और भी सभी भंडार IRepository को लागू करने वर्ग हैं रहते हैं। मैं इसे बिजनेस लेयर, एमवीसी में भी संदर्भित करता हूं। क्या मैं सही कर रहा हूँ? मुझे लगता है कि मैं एक बुरा डिजाइन कर रहा हूँ :(कृपया सुझाव है/मदद

Answer 1

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

इस पर निर्भर करता है कि आप अपनी परतों को अलग करते हैं (अलग-अलग असेंबली या असेंबली के भीतर अलग-अलग फ़ोल्डर्स) इस बात पर निर्भर करता है कि आपने अपनी पीओसीओ कक्षाएं कहां रखी हैं। अगर विभिन्न असेंबली (जो अधिकांश परियोजनाओं के लिए अधिक है) तो एक अन्य 'आम' असेंबली अन्य सभी द्वारा संदर्भित है करने के लिए स्थान पीओसीओ कक्षाएं डालें। यदि अलग-अलग फ़ोल्डर्स हैं, तो 'मॉडल' या 'DomainModels' नामक फ़ोल्डर एक स्थान है।

विशेष रूप से एक एमवीसी अनुप्रयोग के लिए, मैं अपने पॉको वर्गों को 'मॉडल' फ़ोल्डर में रखूंगा (मेरे पास 'व्यू मॉडेल' फ़ोल्डर भी है), और मेरा एडीएमएक्स एक बीएलएल फ़ोल्डर में जिसे मैं कभी-कभी 'तर्क' कहता हूं।

यदि आपको परीक्षण के लिए एक कमजोर युग्मित आर्किटेक्चर की आवश्यकता है, तो आपके स्वयं के भंडार पैटर्न में लिपटे ईएफ संदर्भ के साथ रेपॉजिटरीज़ नामक एक फ़ोल्डर जाने का तरीका है।

Answer 2

दाल

• FAL
• साल
• एफई (यहां आप सामान्य भंडार पर UnitOfWork का प्रयोग करेंगे (क्योंकि यह बदल सकते हैं और प्रदर्शन मामलों ध्यान देना चाहिए))

बीएल (यहां आप उपयोग के अंतराल के अनुसार इस परत को अलगाव के लिए आईओसी (यूनिटी या निनजेक्ट) का उपयोग करेंगे, जैसे परीक्षण ...)

• बीएल Testable दाल प्रबंधक

MVC

• मॉडल
• दृश्य
• नियंत्रक

unittest (मजाक)

मुझे लगता है कि यह सबसे अच्छा मीटर है odel

Answer 3

क्योंकि दुर्भाग्यवश दुर्भाग्य से डेटाबेस बनाने के निर्णय से गंभीर रूप से विकलांग हैं, तो आपको Anti-Corruption layer प्रति Eric Evans' Domain-Driven Design का उपयोग करने की आवश्यकता होगी।

यह एक अच्छा समाधान है जब आपको एक शर्मीली इंटरफ़ेस दिया जाता है जिसे आपको बिल्कुल कोड करना चाहिए - डीबी के चारों ओर एक इंटरफ़ेस लपेटें जो जिस तरह से आप चाहते हैं उससे व्यवहार करता है। भ्रष्टाचार विरोधी परत को छोड़कर किसी भी ईएफ कक्षाओं को सीधे किसी भी चीज़ का पर्दाफाश न करें।

public class SomeReadService : ISomeReadService { 
    public SomeViewModel Load(Guid id) { 
    using (var dbContext = new DbContext()) { 
     // Query the DB model, then *map* the EF classes to SomeVieWModel. 
     // This way you are not exposing the shitty DB model to the outside world. 
    } 
    } 
} 

यहाँ एक लेखन उदाहरण है::

public class SomeRepository : ISomeRepository { 
    public SomeDomainObject Load(Guid id) { 
    using (var dbContext = new DbContext()) { 
     // Map the EF classes to your domain object. Same idea as before. 
    } 
    } 
} 

मैं अभी भी ग्राहक को प्रदर्शित करने के लिए कि एक अलग टीम डिजाइन होने डीबी एक आपदा हो जाएगा की कोशिश करेगा (

यहाँ एक पढ़ने उदाहरण है और मेरा अनुभव दृढ़ता से इंगित करता है कि यह होगा)। देखें कि क्या कोई तरीका है कि आप फीडबैक प्रदान कर सकते हैं जो क्लाइंट को दिखाएगा कि अगर आप डीबी डिज़ाइन करते हैं तो यह बेहतर होगा।

Answer 4

अपने रेपो पैटर्न में

लपेटें संदर्भ, और एक फ़ोल्डर बुलाया खजाने जहां BLL है में रखें ... हाँ, लेकिन यह आपके संदर्भ जगह (मुझे नहीं MVC में मॉडल के साथ सहमत) में सामान्य का उपयोग करें और एक साथ हल बीएल में कंटेनर क्योंकि tesability। हाँ आप सही हैं ईएफ मानक में डीएएल होना चाहिए। मॉडल सभी परियोजनाओं के साथ एकीकृत अन्य परत होना चाहिए लेकिन हो सकता है कि पॉको न हो। हां आपका रैपर उदाहरण जेनेरिक रिपोजिटरी पैटर्न समझाता है लेकिन यूनिटऑफवर्क (यदि आपको आवश्यकता हो) के आधार पर आईआरपीओ इंटरफेस भी होना चाहिए। और यदि आप डोमेन पर अपनी पृथक बीएल परत को हल करते हैं तो आप सही तरीके से रास्ते पर हैं। मुझे लगता है कि बुद्धि = 180 :)

Answer 5

कृपया नीचे दिए गए प्रश्न के समान प्रकार के लिए एसओ लिंक देखें:

With a database-first approach, how do I separate my Core and Infrastructure layers?

आशा इस मदद करता है !!