ईएफ, यूओडब्ल्यू और रिपोजिटरी - वेबफॉर्म में यूनिटऑफवर्क का निपटान कब करें?

Question

हाल ही में मैंने एंटीटीफ्रेमवर्क की खोज के साथ रिपोजिटरी पैटर्न और यूनिटऑफवर्क की अवधारणा में खुदाई शुरू कर दी।

एक MVC उदाहरण के आधार पर अपने खुद के कार्यान्वयन बनाया गया है, जहां वे तो जैसे नियंत्रक से UnitOfWork निपटाने गया:

protected override void Dispose(bool disposing) 
{ 
    unitOfWork.Dispose(); 
    base.Dispose(disposing); 
} 

मैं MVC में सब पर, और बहुत वेबफ़ॉर्म में नए रूप में अच्छी तरह नहीं कर रहा हूँ, लेकिन मुझे लगता है कि यूनिटऑफवर्क को "सबकुछ" के रूप में निपटाने के लिए वे नियंत्रक निपटान विधि को ओवरराइड कर रहे हैं।

मूल रूप से मैं अपने एएसपी.नेट वेबफॉर्म वेबसाइट में एक ही अवधारणा को कार्यान्वित करना चाहता हूं और यूनिटऑफवर्क का निपटान करना चाहता हूं जिसका उपयोग पृष्ठ के कोड के पीछे पृष्ठ के निपटारे के साथ किया जाता है।

मैंने इसे जीवन चक्र से पृष्ठ_Unload ईवेंट में जोड़ने पर विचार किया, लेकिन मुझे यकीन नहीं था कि ऐसा करने का यह सही तरीका है क्योंकि मैंने पहले ऐसी चीजों से गड़बड़ नहीं की है। मेरा विचार इस प्रकार है:

protected void Page_Unload(object sender, EventArgs e) 
{ 
    unitOfWork.Dispose(); 
    base.Dispose(); 
} 

मैं इसे सुरक्षित रूप से कैसे प्राप्त कर सकता हूं, और क्या मैं सही रास्ते पर हूं?

Answer 1

सबसे पहले: पहिया का आविष्कार न करें।

उपयोग निर्भरता इंजेक्शन फ्रेमवर्क की तरह: StructureMap, Ninject, एकता, आदि ....

आपका UOW एक वेब अनुरोध और की शुरुआत के साथ शुरू किया जाना चाहिए निपटारा जब अनुरोध समाप्त हो गया है।

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

लेकिन यदि आप इसे स्वयं करने का प्रयास करते हैं, तो आप एक निर्भरता इंजेक्शन ढांचे का उपयोग करके गलत तरीके से हैं, यह इतना आसान बना देगा।

ढांचा आपके डेटाकॉन्टेक्स्ट (यूओडब्लू) के जीवनकाल को संभाल सकता है।

Answer 2

आप परतों और घटकों में अपने सॉफ्टवेयर को विभाजित करना चाहिए ...

यूआई -> नियंत्रक -> सेवा -> दाल

जैसे

UI.Submit -> Controller.SaveUserInfo -> UsersManagementService.SaveUserInfo ->

public void SaveUserInfo(User user) 
{ 
    using (var uow = new Uow()) 
    { 
     var dbUser = uow.Users.GetByKey(user.Id); 
     if (dbUser == null) 
     { 
      // TODO: 
     } 

     dbUser.Name = user.Name; 
     dbUser.Address = user.Address; 
     // Or use a framework for injecting properties 

     uow.SaveAndAcceptChanges(); 
    } 
} 

तुम भी जैसे certiain सेवा तरीकों में क्वेरी तर्क प्राप्त कर सकते हैं

public User GetUsersMatching(Func<IQueryable<User>, IQueryable<User>> query) 
{ 
    using (var uow = new Uow()) 
    { 
     var users = query(uow.Users).ToList(); 
     return users; 

     // For this to work using POCOs you may need to disable proxy creation 
    } 
} 

हालांकि, इस परीक्षण को और अधिक जटिल बना देता है और सेवा के उपभोक्ताओं संस्थाओं के लिए सीमाओं और LINQ की सर्वोत्तम प्रथाओं को समझने के लिए की आवश्यकता है।

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

इसके बजाय अपनी सेवाओं का डोमेन-speicifc-repositories के रूप में व्यवहार करें जहां आप विभिन्न प्रकार के आउटपुट प्राप्त कर सकते हैं। या दूसरे शब्दों में, अपने एमवीसी के तहत और अपने ईएफ के ऊपर एसओए का उपयोग करें।