रिपोजिटरी पैटर्न का उपयोग क्यों करें या कृपया मुझे यह समझाएं?

Question

मैं रिपोजिटरी पैटर्न सीख रहा हूं और Repository Pattern with Entity Framework 4.1 and Code First और Generic Repository Pattern - Entity Framework, ASP.NET MVC and Unit Testing Triangle पढ़ रहा था कि वे एंटीटी फ्रेमवर्क के साथ रिपोजिटरी पैटर्न को कैसे कार्यान्वित करते हैं।

ऊपरी परत
• से

• छिपाएं एफई कह कोड बेहतर परीक्षण योग्य

मेक कोड बेहतर परीक्षण योग्य मैं समझता हूँ करते हैं, लेकिन क्यों ऊपरी परत से छिपाने एफई?

उनके कार्यान्वयन को देखते हुए, ऐसा लगता है कि इकाई ढांचे की क्वेरी के लिए एक सामान्य विधि के साथ इकाई ढांचे को लपेटें। असल में ऐसा करने का क्या कारण है?

मैं यह सोचते हैं हूँ

1. ढीला युग्मन (कि ऊपरी परत से क्यों छिपाने एफई है?)
2. बचें दोहराने समान क्वेरी

हूँ मैं सही ढंग से इस बात को समझ के लिए एक ही LINQ बयान writting के लिए है ?

अगर मैं एक DataAccessLayer जो एक वर्ग है लिखने तरीकों

QueryFooObject(int id) 
{ 
..//query foo from entity framework 
} 

AddFooObject(Foo obj) 
{ 
.. //add foo to entity framework 
} 
...... 
QueryBarObject(int id) 
{ 
.. 
} 

AddBarObject(Bar obj) 
{ 
... 
} 

कि यह भी एक भंडार पैटर्न है? डमी के लिए

Explaination महान :)

Answer 1

एक बात यह है कि टेस्टेबिलिटी में वृद्धि हो और अंतर्निहित दृढ़ता प्रौद्योगिकी के लिए ढीला युग्मन हो। लेकिन आपके पास कुल रूट ऑब्जेक्ट प्रति एक भंडार भी होगा (उदाहरण के लिए, ऑर्डर एक समग्र रूट हो सकता है, जिसमें ऑब्जेक्ट लाइन (जो कुल रूट नहीं हैं), डोमेन ऑब्जेक्ट दृढ़ता को अधिक सामान्य बनाने के लिए।

यह भी बनाता है ऑब्जेक्ट्स को प्रबंधित करना बहुत आसान है, क्योंकि जब आप ऑर्डर सहेजते हैं, तो यह आपके बच्चे के आइटम भी सहेज लेगा (जो ऑर्डर लाइन हो सकते हैं)

Answer 2

भंडार प्रणाली के परीक्षण के लिए अच्छे हैं हो जाएगा।

एक कारण यह है कि आप निर्भरता इंजेक्शन का उपयोग कर सकते हैं।

असल में आप अपने भंडार के लिए एक इंटरफ़ेस बनाते हैं, और जब आप ऑब्जेक्ट बना रहे होते हैं तो आप इसके लिए इंटरफ़ेस का संदर्भ देते हैं। फिर आप बाद में एक नकली वस्तु बना सकते हैं (उदाहरण के लिए moq का उपयोग कर) जो कि इंटरफ़ेस लागू करता है। निंजा जैसी कुछ का उपयोग करके आप उस इंटरफ़ेस पर उचित प्रकार को बाध्य कर सकते हैं। बूम आपने समीकरण के बाहर निर्भरता ली है और इसे कुछ टेस्टेबल के साथ बदल दिया है।

विचार यह है कि परीक्षण उद्देश्यों के लिए ऑब्जेक्ट्स के कार्यान्वयन को आसानी से स्वैप करने में सक्षम होना आशा है कि यह समझ में आता है।

Answer 3

इसी कारण से आप अपने ऐप में हार्ड कोड फ़ाइल पथ नहीं करते हैं: loose coupling और encapsulation। "C: \ windows \ fonts" के लिए हार्ड कोड किए गए संदर्भों के साथ एक ऐप की कल्पना करें और जो समस्याएं हो सकती हैं। आपको पथों के लिए हार्ड कोड संदर्भ नहीं करना चाहिए, तो आपको अपनी दृढ़ता परत के लिए हार्ड कोड संदर्भ क्यों चाहिए?कॉन्फ़िगरेशन सेटिंग्स (या special folders या जो भी आपका समर्थन करता है) के पीछे अपने पथ छुपाएं और एक संग्रह के पीछे अपनी दृढ़ता को छुपाएं। यूनिट परीक्षण के लिए यह बहुत आसान होगा, अन्य वातावरणों पर तैनात होगा, कार्यान्वयन स्वैप करेगा, और आपके डोमेन ऑब्जेक्ट्स के बारे में कारण होगा यदि एक रिपोजिटरी के पीछे दृढ़ता की चिंताओं को छुपाया जाता है।

Answer 4

मुझे नहीं लगता कि आपको चाहिए।

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

मैं अपने ब्लॉग पोस्ट में इस बारे में बात की: http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern

मुख्य कारण जोड़ने अपने स्वयं के भंडार कार्यान्वयन है ताकि आप निर्भरता इंजेक्शन का उपयोग करें और अपने कोड और अधिक परीक्षण योग्य बना सकते हैं।

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

मुझे लगता है कि यहाँ के बारे में बात: http://www.nogginbox.co.uk/blog/mocking-entity-framework-data-context

हम एफई परीक्षण योग्य तो मुझे नहीं लगता कि हम यह बिल्कुल क्या ज़रूरत है बनाने के लिए भंडार पैटर्न की जरूरत नहीं है।

Answer 5

यह भी आपके प्रश्नों को केंद्रीय स्थान पर रखने का एक लाभ है; अन्यथा आपके प्रश्न चारों ओर बिखरे हुए हैं और बनाए रखने के लिए कठिन हैं।

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

भंडार का उपयोग (यूनिटऑफवर्क के साथ संयोजन में) इस तर्क को केंद्रीकृत भी कर सकता है।

Here कुछ अच्छे वीडियो के साथ कुछ वीडियो हैं।

Answer 6

इस तस्वीर यह आसान समझने के लिए

Answer 7

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

class StudenRepository 
    { 
    dbcontext ctx; 
    StundentRepository(dbcontext ctx) 
    { 
     this.ctx=ctx; 
    } 
    public void EnrollCourse(int courseId) 
    { 
     this.ctx.Students.Add(new Course(){CourseId=courseId}); 
    } 
    } 

    class TeacherRepository 
    { 
    dbcontext ctx; 
    TeacherRepository(dbcontext ctx) 
    { 
     this.ctx=ctx; 
    } 
    public void EngageCourse(int courseId) 
    { 
     this.ctx.Teachers.Add(new Course(){CourseId=courseId}); 
    } 
    } 

    public class MyunitOfWork 
    { 
    dbcontext ctx; 
    private StudentRepository _studentRepository; 
    private TeacherRepository _teacherRepository; 

    public MyunitOfWork(dbcontext ctx) 
    { 
     this.ctx=ctx; 
    } 

    public StudentRepository StundetRepository 
    { 
     get 
     {  
      if(_studentRepository==null) 
       _stundentRepository=new StundetRepository(this.ctx); 

      return _stundentRepository;  
     } 
    } 

    public TeacherRepository TeacherRepository 
    { 
     get 
     {  
      if(_teacherRepository==null) 
       _teacherRepository=new TeacherRepository (this.ctx); 

      return _teacherRepository;  
     } 
    } 

    public void Commit() 
    { 
     this.ctx.SaveChanges(); 
    } 
    } 

//some controller method 
public void Register(int courseId) 
{ 
    using(var uw=new MyunitOfWork(new context()) 
    { 
    uw.StudentRepository.EnrollCourse(courseId); 
    uw.TeacherRepository.EngageCourse(courseId); 
    uw.Commit(); 
    } 
} 

Answer 8

मुझे पता है, यह बुरा है इस सवाल का जवाब यहाँ में लिंक प्रदान हालांकि वीडियो जो जब यह इकाई की रूपरेखा के साथ प्रयोग भंडार पैटर्न के विभिन्न लाभों बताते साझा करना चाहते थे। नीचे यूट्यूब का लिंक है।

https://www.youtube.com/watch?v=rtXpYpZdOzM

यह भी कैसे ठीक भंडार पैटर्न को लागू करने के बारे में जानकारी प्रदान करता है।