यूनिट ऑफ वर्क डब्ल्यू/ईएफ 4, आईओसी (एकता), और रिपोजिटरी कहां से संबंधित है?

Question

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

मैं यह पता लगाने की कोशिश कर रहा हूं कि मेरा यूनिटऑफवर्क संबंधित है - और विशेष रूप से, बनाया जाता है - जब रिपोजिटरी पैटर्न के साथ ईएफ 4 और एकता का उपयोग करते हैं।

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

काम की मेरी इकाई, हालांकि, ईएफ 4 संदर्भ (या, मेरे मामले में, और संदर्भ के इंटरफ़ेस - IObjectContext) के साथ इंजेक्शन की आवश्यकता है। और मुझे यकीन नहीं है कि यूओडब्ल्यू को बनाया जाना चाहिए और संदर्भ/इंजेक्शन इंजेक्शन दिया जाना चाहिए।

यहाँ संभव विकल्प मैं, जिनमें से कोई भी सोच सकते हैं लगते आदर्श हैं:

• , सेवा निर्माता में UOW शामिल इस प्रकार सेवा/काम की इकाई, w इंजेक्शन होने जो बारी में इंजेक्शन w/मेरा ईएफ 4 संदर्भ है। लेकिन यह गलत लगता है क्योंकि मैं नहीं चाहता कि मेरा यूओडब्ल्यू रिपोजिटरी के हर उदाहरण पर बनाया गया हो।

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

• सीधे संदर्भ में संदर्भ को इंजेक्ट करें, जिससे मुझे यूओडब्ल्यू (संदर्भ) बनाने की अनुमति मिलती है। यह बुरा लगता है क्योंकि अब मैंने सेवा के संदर्भ को उजागर किया है, और इसे भंडार के लिए अलग किया जाना चाहिए।

तो मेरा सवाल यह है कि, इनमें से एक तरीका स्वीकार्य है, या क्या कोई और तरीका है जिसके बारे में मैं सोच नहीं रहा हूं?

अग्रिम धन्यवाद।

Answer 1

शायद इसका उपयोग करने के कई तरीके हैं इसलिए मैं एक उपयोगी वर्णन करता हूं जिसे मैं उपयोगी पाया।

इमो जो यूओडब्ल्यू को परिभाषित करने का स्थान एप्लिकेशन तर्क में है - वह तर्क जो आपकी व्यावसायिक परत (व्यावसायिक सेवाएं) कहता है। इसका कारण यह है कि यूओडब्ल्यू को लॉजिकल बिजनेस ट्रैसैक्शन का प्रतिनिधित्व करना चाहिए - एप्लिकेशन लॉजिक (या दूरस्थ कॉल के मामले में सेवा मुखौटा) तार्किक लेनदेन क्या परिभाषित करता है। तो MVC में उदाहरण के लिए आप जहां प्रत्येक नियंत्रक कार्रवाई एकल UOW का प्रतिनिधित्व करता है वास्तुकला के साथ जा सकते हैं: इस उदाहरण मेरी नियंत्रक दो व्यावसायिक सेवाओं पर depenent जाता है

public class MyController : Controller 
{ 
    public MyController(IFirstService firstService, ISecondService secondService, 
    IUnitOfWork unitOfWork) 
    { ... } 

    [HttpPost] 
    public ActionResult SomeAction(Model data) 
    { 
    _firstService.SomeProcessing(data); 
    _secondService.SomeProcessing(data); 
    _unitOfWork.SaveChanges(); 
    return RedirectToAction(...); 
    } 
} 

और कार्रवाई उन दोनों को कॉल - UOW तो दोनों सेवाओं के द्वारा किया जाता परिवर्तनों को सहेजने । यही कारण है कि मुझे लगता है कि यूओडब्ल्यू नियंत्रक में उपलब्ध होना चाहिए क्योंकि यदि आपकी एप्लिकेशन परत में यूओडब्लू तक पहुंच नहीं है तो आप कई तर्क कॉलों से अपने तर्क को दोबारा लिख ​​सकते हैं (क्योंकि प्रत्येक संभवतः अपने स्वयं के सेव चेंज को कॉल करता है)।

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

_firstService.SomeProcessing(data); 
_secondService.SomeProcessing(data); 
_unitOfWork.SaveChanges(); 

इस तरह के मामले UOW में लेकिन नियंत्रक को सेवा के लिए मुखौटा और सेवा मुखौटा नियंत्रक को इंजेक्ट किया जाएगा नहीं पहुंच पाएगी। यदि आप अपने व्यापार तर्क को वेब सेवा (या अन्य दूरस्थ तकनीक) पर उजागर करेंगे तो आप निश्चित रूप से इस दृष्टिकोण का उपयोग करेंगे।

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

Answer 2

इसका प्रबंधन करने का एक तरीका है http://mfelicio.wordpress.com/2010/02/07/managing-the-entity-framework-objectcontext-instance-lifetime-in-wcf-and-sharing-it-among-repositories/ में वर्णित विधि का उपयोग करना यह आलेख Wcf सेवाओं के लिए ContextManager लागू करता है। एएसपी.नेट ऐप के लिए हम इस तरह कुछ इस्तेमाल कर सकते हैं।

public class AspNetDBContextManager<TContext> : IDBContextManager 
    where TContext : IDBContext, new() 
{ 
    #region IDBContextManager Members 

    public IDBContext GetDBContext() 
    { 
     return this.GetOrCreateDbContext(); 
    } 

    private IDBContext GetOrCreateDbContext() 
    { 
     if (HttpContext.Current == null) 
     { 
      throw new InvalidOperationException("Can be used only within ASP.NET applications"); 
     } 

     string dbContextKey = string.Format("__AspNetDBCM__{0}__", HttpContext.Current.GetHashCode()); 

     object dbContext = HttpContext.Current.Items[dbContextKey]; 

     if (dbContext == null) 
     { 
      dbContext = new TContext(); 

      if (dbContext != null) 
      { 
       HttpContext.Current.Items[dbContextKey] = dbContext; 
      } 
     } 

     return dbContext as IDBContext; 
    } 

    #endregion 
} 

public interface IDBContext 
{ 
    object Context { get; } 
} 


public interface IDBContextManager 
{ 
    IDBContext GetDBContext(); 
}