ईएफ के साथ एक एएसपी.NET एमवीसी ऐप आर्किटेक्ट कैसे करें?

Question

मुझे एन-टायर ऐप में एंटिटी फ्रेमवर्क के साथ एक एमवीसी ऐप को आर्किटेक्ट करने का तरीका समझने में थोड़ा सा परेशानी हो रही है।

सामान्य, पाठ्यपुस्तक 3-स्तरीय एप्लिकेशन

डाटा Access-> व्यवसाय Logic- की तरह कुछ> प्रस्तुति देखने के

प्रस्तुति डेटा का उपयोग के बारे में कुछ भी पता नहीं करना चाहिए करना चाहिए। ईएफ के साथ, सभी परतों को मॉडल के बारे में जानने की जरूरत है। तो मेरा आर्किटेक्चर अब

Data Access->Business Logic 
    |    | 
     --------------- 
      | 
      MVC 

क्या मुझे यहां कुछ याद आ रहा है या क्या मैं गलत तरीके से इस बारे में सोच रहा हूं?

क्या मुझे डेटा एक्सेस लेयर के रूप में ईएफ के बारे में सोचना चाहिए और संस्थाओं को व्यावसायिक तर्क में रखना चाहिए?

Answer 1

ठीक है, मुझे लगता है कि आपका प्रश्न है, कैसे एमवीसी अनुप्रयोग में "परतें" आर्किटेक्ट करने के लिए। इस सरल वास्तुकला पर एक नज़र डालें, मैं इसे अपने एमवीसी ऐप्स के लिए उपयोग करता हूं और यह साफ और कुशल प्रतीत होता है।

1. समाधान में परियोजना - व्यापार मॉडल - व्यवसाय डोमेन का प्रतिनिधित्व करने वाले पीओसीओ वर्गों से भरा सरल वर्ग पुस्तकालय। आप यहां डेटा एनोटेशन का उपयोग कर सकते हैं, सत्यापन तर्क के लिए मेटाडेटा कक्षाएं, आदि

2. प्रोजेक्ट - ईएफ-आधारित रिपॉजिटरीज़ - एक और सरल वर्ग लाइब्रेरी; यहां परिभाषित संदर्भ है (ईएफ कोड पहले महान है, लेकिन आप पहले ईएफ डेटाबेस का उपयोग कर सकते हैं या पहले मॉडल का उपयोग कर सकते हैं - आपको बस बिजनेस मॉडल क्लास लाइब्रेरी में कोई भी बड़ा सौदा नहीं है), और कक्षाओं का सेट - रिपॉजिटरीज

3. प्रोजेक्ट - मैं आमतौर पर इसे "सर्विसलेयर" कहता हूं या इसलिए (मैं बेहतर नाम के लिए सुझाव के लिए खुला हूं :) - इसमें केवल इंटरफेस हैं, रिपॉजिटरीज और अन्य सेवाओं के लिए (अलग-अलग परियोजनाओं में लागू) जो मेरी एमवीसी (या कोई अन्य तकनीक)) आधारित आवेदन उपयोग; 2.प्रोजेक्ट से रिपोजिटरीज इन इंटरफेस को लागू करें

4. प्रोजेक्ट - एमवीसी वेबसाइट। यह रिपोजिटरी मैपिंग (और अन्य सेवाओं) के लिए निर्भरता इंजेक्शन (निर्भरता रेसोलवर में निर्मित, और मुझे निंजा कंटेनर का उपयोग करना पसंद है) का उपयोग करता है; तो फिर तुम नियंत्रकों में निर्माता इंजेक्शन का उपयोग कर सकते हैं, या कुछ "सुस्त" दृष्टिकोण (नीचे देखें)

यह इस तरह दिखता है:

स्किनी नियंत्रक:

 
public class SomethingController : BaseController 
{ 
    public ActionResult DoSomething(SomeBusinessThing input) 
    { 
     if (ModelState.IsValid) 
     { 
      var result = CustomerRepository.DoSomeBusinessLogicAndPersistenceAndStuff(input); 
      return View(result); // you can use AutoMapper here, if you dont want to use business object as viewmodels 
     } 
    } 
} 

मेरे भंडार "संपत्ति "मेरे बेसकंट्रोलर से विरासत में मिला है:

 
public class BaseController : Controller 
{ 
    // ... other stuff used by all (or multiple) controllers 

    private ICustomerRepository _customerRepository; 
     protected ICustomerRepository CustomerRepository 
     { 
      get 
      { 
       if (_customerRepository== null) 
        _customerRepository= DependencyResolver.Current.GetService(); 
       return _customerRepository; 
      } 
     } 
} 

यदि आप अपने" आलसी "DI का उपयोग कर सकते हैं तो नियंत्रक कई सेवाओं का उपयोग करता है, लेकिन केवल 1-2 प्रति क्रिया है, इसलिए यह सभी को कन्स्ट्रक्टर के साथ इंजेक्ट करने के लिए अक्षम होगा।कोई आपको बता सकता है कि आप इस तरह निर्भरता "छुपा" कर रहे हैं, लेकिन यदि आप इन सभी चीजों को एक ही स्थान पर रखते हैं - बेसकंट्रोलर, इसका कोई बड़ा सौदा नहीं है।

ठीक है, भंडार का कार्यान्वयन वास्तव में आपका व्यवसाय है। MVC आवेदन न भी आप एफई उपयोग कर रहे हैं पता है, यह सेवाओं की केवल इंटरफेस जानता है और कार्यान्वयन underlaying के बारे में देखभाल नहीं करता

Conslusion (जो आप बाद में कभी भी अगर आप की जरूरत है स्विच कर सकते हैं!):

• नियंत्रकों पतला कर रहे हैं - कोई व्यापार तर्क

• मॉडल फैट है - और इस मामले में, खजाने सभी व्यापार तर्क को संपुटित (क्या आप वाकई सेवाओं के अन्य प्रकार के रूप में अच्छी तरह से उदाहरण के लिए कुछ कैलकुलेटर आदि के प्रसंस्करण के लिए उपयोग कर सकते हैं, तो याद रखें , एमवीसी परवाह नहीं है, ओएनएल जानता है y इंटरफेस)

• ViewModels दृश्य के लिए इनपुट कर रहे हैं (और ViewModel आपके व्यवसाय मॉडल सीधे हो सकता है, या आप "शुद्ध" ViewModels) बनाने के लिए AutoMapper उपयोग कर सकते हैं

Answer 2

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

Answer 3

मैं तुम सच में अच्छा सिफारिश कर सकते हैं (मैं सोचें) .NET प्लेटफ़ॉर्म पर डोमेन संचालित आर्किटेक्चर डिज़ाइन के बारे में पुस्तक। बुक सी को .NET 4.0 के साथ एन-स्तरित डोमेन संचालित आर्किटेक्चर गाइड कहा जाता है। पुस्तक में बताया गया है कि ईएफ और एमवीसी के साथ अच्छी वास्तुकला कैसे बनाएं (और सिल्वरलाइट जैसी कई अन्य चीजें, यूनिटी आदि के साथ आईओसी)।

बुक इस पते पर डाउनलोड किया जा सकता:

http://microsoftnlayerapp.codeplex.com/

सबसे अच्छा तरीका है POCO कक्षाएं स्वतंत्र पैदा कर रही है एफई के लिए संस्थाओं को बनाने का तरीका:

http://msdn.microsoft.com/es-es/architecture/en/

इसके अलावा नमूना आवेदन बहुत ही दिलचस्प है लगातार परत पर। इन डोमेन इकाइयों को डोमेन (व्यापार) तर्क परत में शामिल किया गया है।

पुस्तक में यह भी समझाया गया है कि आवेदन प्रस्तुति, एप्लाइक्शन, डोमेन, इंफ्रास्ट्रक्चर (अधिकतर डेटा दृढ़ता), क्रॉस-कटिंग और वितरित सेवाओं की परतों को समझाते हुए अधिक परतों में विचलित होना चाहिए।