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

203

एक नौकरी के साक्षात्कार के दौरान, मुझे यह बताने के लिए कहा गया था कि रिपॉजिटरी पैटर्न, ओआरएम के साथ काम करने के लिए एक अच्छा पैटर्न क्यों नहीं है जैसे कि एंटिटी फ्रेमवर्क। यह एक केस क्यों है?

asp.net-mvc entity-framework unit-of-work

— StringBuilder
स्रोत

60

यह एक

— ट्रिकी

2

मैंने शायद साक्षात्कारकर्ता को उत्तर दिया होगा कि Microsoft रिपॉजिटरी पैटर्न का उपयोग अक्सर करते हैं जब वे इकाई रूपरेखा प्रदर्शित करते हैं: | ।

— लॉरेंट बोर्गुल्ट-रॉय

1

तो क्या साक्षात्कारकर्ता के लिए यह एक अच्छा विचार नहीं होने का कारण था?

— बॉब हॉर्न

3

मज़ेदार तथ्य यह है कि Google में "रिपॉजिटरी पैटर्न" की खोज परिणाम देती है जो ज्यादातर एंटिटी फ्रेमवर्क से संबंधित हैं और ईएफ के साथ पैटर्न का उपयोग कैसे करें।

— आर्सेनी मूरज़ेंको

2

ayende का ब्लॉग ayende.com/blog देखें । मुझे जो पता है उसके आधार पर, उन्होंने रिपॉजिटरी पैटर्न का उपयोग किया लेकिन अंततः इसे क्वेरी ऑब्जेक्ट पैटर्न के पक्ष में छोड़ दिया

— Jaime Sangcap

99

मैं रिपॉजिटरी पैटर्न के लिए एंटिटी फ्रेमवर्क के साथ काम नहीं करने का कोई कारण नहीं देखता हूं। रिपॉजिटरी पैटर्न एक अमूर्त परत है जिसे आपने अपने डेटा एक्सेस लेयर पर रखा है। आपकी डेटा एक्सेस लेयर शुद्ध ADO.NET संग्रहित प्रक्रियाओं से लेकर Entity Framework या XML फ़ाइल तक कुछ भी हो सकती है।

बड़ी प्रणालियों में, जहां आपके पास विभिन्न स्रोतों (डेटाबेस / एक्सएमएल / वेब सेवा) से आने वाले डेटा हैं, एक अमूर्त परत होना अच्छा है। इस परिदृश्य में रिपोजिटरी पैटर्न अच्छा काम करता है। मुझे विश्वास नहीं है कि पर्दे के पीछे क्या हो रहा है इसे छिपाने के लिए एंटिटी फ्रेमवर्क पर्याप्त अमूर्त है।

मैंने अपने डेटा एक्सेस लेयर विधि के रूप में एंटिटी फ्रेमवर्क के साथ रिपॉजिटरी पैटर्न का उपयोग किया है और अभी तक एक समस्या का सामना करना पड़ रहा है।

DbContextरिपॉजिटरी के साथ अमूर्त करने का एक और फायदा यूनिट-टेस्टिबिलिटी है । आपके पास अपना IRepositoryइंटरफ़ेस हो सकता है जिसमें 2 कार्यान्वयन हैं, एक (वास्तविक रिपॉजिटरी) जो DbContextडेटाबेस और दूसरे से बात करने के लिए उपयोग करता है, FakeRepositoryजो इन-मेमोरी ऑब्जेक्ट्स / मॉकडॉट डेटा को वापस कर सकता है। यह आपकी IRepositoryइकाई-परीक्षण योग्य बनाता है , इस प्रकार कोड के अन्य भागों का उपयोग करता है IRepository।

public interface IRepository
{
  IEnumerable<CustomerDto> GetCustomers();
}
public EFRepository : IRepository
{
  private YourDbContext db;
  private EFRepository()
  {
    db = new YourDbContext();
  }
  public IEnumerable<CustomerDto> GetCustomers()
  {
    return db.Customers.Select(f=>new CustomerDto { Id=f.Id, Name =f.Name}).ToList();
  }
}
public MockRepository : IRepository
{
  public IEnumerable<CustomerDto> GetCustomers()
  {
    // to do : return a mock list of Customers
    // Or you may even use a mocking framework like Moq
  }
}

अब DI का उपयोग करके, आपको कार्यान्वयन मिलता है

public class SomeService
{
  IRepository repo;
  public SomeService(IRepository repo)
  {
     this.repo = repo;
  }  
  public void SomeMethod()
  {
    //use this.repo as needed
  }    
}

— Shyju
स्रोत

3

मैंने यह नहीं कहा कि यह काम नहीं करेगा, मुझे EF के साथ रिपॉजिटरी पैटर्न के साथ भी काम किया जाता है, लेकिन आज मुझसे पूछा गया कि IT डेटा के साथ पैटर्न का उपयोग करने के लिए IT IS GOOD क्यों नहीं है, अनुप्रयोग जो डेटाबेस का उपयोग कर रहा है

2

ठीक है, क्योंकि यह सबसे लोकप्रिय उत्तर है जिसे मैंने इसे सही उत्तर के रूप में चुना है

65

आखिरी बार कब सबसे लोकप्रिय == सही था?

— एचडीवी

14

DbContext पहले से ही एक रिपॉजिटरी है, रिपॉजिटरी का मतलब निम्न स्तर का अमूर्त होना है। यदि आप अलग-अलग डेटा स्रोतों को सार करना चाहते हैं, तो उन लोगों का प्रतिनिधित्व करने के लिए ऑब्जेक्ट बनाएं।

— डैनियल लिटिल

7

ColacX। हमने कोशिश की है कि - कंट्रोलर लेयर में DBcontext राइट - और हम रेपो पैटर्न पर वापस लौट रहे हैं। रेपो पैटर्न के साथ, यूनिट टेस्ट बड़े पैमाने पर DbContext की नकल करते हुए चले गए जो कि लगातार असफल रहे। EF का उपयोग करना मुश्किल था और EF बारीकियों के लिए शोध के भंगुर और लागत घंटे। अब हमारे पास रेपो के छोटे सरल मोक्स हैं। कोड क्लीनर है। कार्य का पृथक्करण स्पष्ट है। मैं अब भीड़ से सहमत नहीं हूं कि ईएफ पहले से ही रेपो पैटर्न है और पहले से ही परीक्षण योग्य इकाई है।

— 22

434

एंटिटी फ्रेमवर्क के साथ रिपॉजिटरी पैटर्न का उपयोग न करने का सबसे अच्छा कारण? एंटिटी फ्रेमवर्क पहले से ही रिपॉजिटरी पैटर्न को लागू करता है। DbContextआपका UoW (कार्य की इकाई) है और प्रत्येक DbSetभंडार है। इसके ऊपर एक और परत को लागू करना न केवल निरर्थक है, बल्कि रखरखाव को कठिन बनाता है।

लोग पैटर्न के उद्देश्य को साकार किए बिना पैटर्न का पालन करते हैं। रिपॉजिटरी पैटर्न के मामले में, उद्देश्य निम्न स्तर के डेटाबेस क्वेरी तर्क को अमूर्त करना है। अपने कोड में वास्तव में SQL स्टेटमेंट लिखने के पुराने दिनों में, रिपॉजिटरी पैटर्न एक तरीका था जो आपके कोड बेस में बिखरे हुए अलग-अलग तरीकों से SQL को स्थानांतरित करने और इसे एक स्थान पर स्थानीय बनाने का एक तरीका था। एक ORM जैसे कि Entity Framework, NHibernate, आदि इस कोड अमूर्त के लिए एक प्रतिस्थापन है , और इस तरह, पैटर्न की आवश्यकता को नकारता है।

हालांकि, अपने ORM के शीर्ष पर एक अमूर्त बनाने के लिए एक बुरा विचार नहीं है, बस यूओडब्ल्यू / रिपॉजिटरी के रूप में जटिल कुछ भी नहीं है। मैं एक सेवा पैटर्न के साथ जाऊंगा, जहाँ आप एक एपीआई का निर्माण करते हैं जिसे आपका एप्लिकेशन बिना जाने या परवाह किए उपयोग कर सकता है कि डेटा एंटिटी फ्रेमवर्क, एनएचबर्नेट, या वेब एपीआई से आ रहा है या नहीं। यह बहुत सरल है, जैसा कि आप अपने एप्लिकेशन की डेटा को वापस करने के लिए अपने सेवा वर्ग में केवल तरीके जोड़ते हैं। यदि आप एक To-do ऐप लिख रहे थे, उदाहरण के लिए, आपके पास इस सप्ताह होने वाली वस्तुओं को वापस करने के लिए एक सेवा कॉल हो सकती है और अभी तक पूरी नहीं हुई है। आपका सभी ऐप जानता है कि अगर यह जानकारी चाहता है, तो वह उस पद्धति को कॉल करता है। उस पद्धति के अंदर और सामान्य रूप से आपकी सेवा में, आप एंटिटी फ्रेमवर्क या जो भी आप उपयोग कर रहे हैं, उसके साथ बातचीत करते हैं। फिर, यदि आप बाद में ORMs को स्विच करने या वेब API से जानकारी खींचने का निर्णय लेते हैं,

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

— क्रिस प्रैट
स्रोत

68

यह एकमात्र सही उत्तर प्रतीत होता है।

— माइक चेम्बरलेन

10

आप EF6 + (देखें: msdn.microsoft.com/en-us/data/dn314429.aspx ) में मॉक कर सकतेDbContext हैं । यहां तक कि कम संस्करणों में, आपको एक नकली उपयोग कर सकते हैं की तरह वर्ग मज़ाक उड़ाया साथ है, के बाद से , औजार एक iterface । DbContextDbSetDbSetIDbSet

— क्रिस प्रैट

14

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

— क्रिस प्रैट

10

अहंकारी लगने के जोखिम पर: वे गलत हैं। अब, जहां तक आधिकारिक ट्यूटोरियल जाते हैं, माइक्रोसॉफ्ट ने EF6 के बाद से जो मैंने देखा है, उससे रिपॉजिटरी का उपयोग करके बंद कर दिया है। पुस्तक के बारे में, मैं नहीं बोल सकता कि लेखक ने रिपॉजिटरी का उपयोग क्यों चुना। मैं क्या बात कर सकता हूं, जैसा कि खाइयों में कोई व्यक्ति बड़े पैमाने पर अनुप्रयोगों का निर्माण करता है, यह है कि एंटिटी फ्रेमवर्क के साथ रिपॉजिटरी पैटर्न का उपयोग करना एक रखरखाव दुःस्वप्न है। एक बार जब आप कुछ प्रकार के रिपॉजिटरी से अधिक जटिल हो जाते हैं, तो आप अपने रिपॉजिटरी / कार्य की इकाई का प्रबंधन करने में समय की अत्यधिक मात्रा में खर्च करते हैं।

— क्रिस प्रैट

6

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

— क्रिस प्रैट

45

यहाँ एक आयेंड रहियन से लिया गया है: कयामत के गड्ढे में स्थापत्य: रिपॉजिटरी एब्सट्रैक्शन लेयर की बुराइयाँ

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

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

ये जटिल समस्याएं हैं जिन्हें एक जटिल समाधान की आवश्यकता है। आप इसे केवल यह दिखावा करके ठीक नहीं कर सकते हैं कि आपकी सभी इकाइयाँ उनके बीच कोई संबंध नहीं के साथ अलग-अलग प्रकार की हैं और प्रत्येक को अपने स्वयं के भंडार में रखती हैं। वैसे आप कर सकते हैं , लेकिन यह बेकार है।

अपडेट: मुझे एंटिटी फ्रेमवर्क के लिए एफर्ट प्रोवाइडर के उपयोग से कुछ सफलता मिली है । प्रयास एक इन-मेमोरी प्रदाता (ओपन सोर्स) है जो आपको परीक्षण में ईएफ का उपयोग करने की अनुमति देता है ठीक उसी तरह जिस तरह आप एक वास्तविक डेटाबेस के खिलाफ इसका उपयोग करेंगे। मैं इस परियोजना में सभी परीक्षणों को बदलने पर विचार कर रहा हूं, मैं इस प्रदाता का उपयोग करने के लिए काम कर रहा हूं, क्योंकि यह चीजों को इतना आसान बनाता है। यह एकमात्र समाधान है जो मैंने अब तक पाया है जो उन सभी मुद्दों को संबोधित करता है जिन्हें मैं पहले के बारे में बता रहा था। केवल एक चीज में थोड़ी देरी होती है जब मेरे परीक्षण शुरू करते हैं क्योंकि यह इन-मेमोरी डेटाबेस बना रहा है (यह ऐसा करने के लिए NMemory नामक एक अन्य पैकेज का उपयोग करता है), लेकिन मैं इसे वास्तविक समस्या के रूप में नहीं देखता हूं। एक कोड प्रोजेक्ट लेख है जो परीक्षण के लिए एफर्ट (बनाम एसक्यूएल सीई) का उपयोग करने की बात करता है।

— luksan
स्रोत

3

इकाई परीक्षण का उल्लेख किए बिना किसी भी वास्तुकला लेख को स्वचालित रूप से मेरे लिए कचरा बिन में भेजा जाता है। रिपॉजिटरी पैटर्न का एक बिंदु कुछ परीक्षण-क्षमता हासिल करना है।

— स्लीपर स्मिथ

3

EF प्रसंग (जो पहले से ही एक भंडार है) को लपेटे बिना आप अभी भी इकाई परीक्षण कर सकते हैं। आपको अपने डोमेन / सेवाओं का परीक्षण करना चाहिए न कि डेटाबेस क्वेरी (वे एकीकरण परीक्षण हैं)।

— डैनियल लिटिल

2

संस्करण 6 में ईएफ की परीक्षा में बहुत सुधार हुआ है DbContext। अब आप पूरी तरह से नकली हो सकते हैं । भले ही, आप हमेशा मज़ाक कर सकते हैं DbSet, और यह एंटिटी फ्रेमवर्क का मांस है, वैसे भी। एक स्थान (काम की इकाई) में DbContextअपने DbSetगुणों (रिपॉजिटरी) को रखने के लिए एक वर्ग से थोड़ा अधिक है , विशेष रूप से एक इकाई परीक्षण संदर्भ में, जहां सभी डेटाबेस इनिशियलाइज़ेशन और कनेक्शन सामान की आवश्यकता नहीं है या किसी भी तरह की आवश्यकता नहीं है।

— क्रिस प्रैट

संबंधित इकाई नेविगेशन को खोना बुरा है और काउंटर OOP है, लेकिन आपके पास इस बात पर अधिक नियंत्रण होगा कि किस बात पर ध्यान दिया जा रहा है।

— एलिर्ज़ा

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

— सुधांशु मिश्रा

16

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

— नौ पूंछे
स्रोत

क्या आप कृपया "एंटिटी फ्रेमवर्क के लिए आपको कोडिंग और कार्यात्मक लाभ का खजाना देते हैं" के कुछ फायदे बता सकते हैं?

— मणिराजएसएस

2

उसका यही मतलब है। var id = Entity.Where (i => i.Id == 1337) .Single () इनकैप्सुलेट किया गया है और इसे एक रिपॉजिटरी में लपेटते हैं, आप मूल रूप से बाहर से इस तरह से क्वेरी लॉजिक नहीं कर सकते हैं, जो या तो आपको A को और अधिक कोड जोड़ने के लिए मजबूर करता है। आईडी लाने के लिए रिपॉजिटरी और इंटरफ़ेस। B रिपॉजिटरी से निकाय संदर्भ लौटाएं ताकि आप क्वेरी लॉजिक लिख सकें (जो कि सिर्फ बकवास है)

— ColacX

14

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

रिपोजिटरी पैटर्न पर पुनर्विचार

— धूम तान
स्रोत

मुझे लेख पसंद आया, लेकिन एंटरप्राइज़ ऐप्स के लिए IMHO, DAL और Bl MUST हैवी फीचर के बीच की अमूर्त परत, क्योंकि आपको पता नहीं था कि कल क्या उपयोग किया जाएगा। लेकिन लिंक साझा करने के लिए धन्यवाद

1

हालांकि व्यक्तिगत रूप से मुझे लगता है कि यह सच है उदाहरण के लिए NHibernate ( ISessionFactoryऔर ISessionआसानी से नकली हैं), यह DbContextदुर्भाग्य से आसान नहीं है ...

— पैट्रिक

6

रिपॉजिटरी पैटर्न का उपयोग करने का एक बहुत अच्छा कारण आपके व्यापार तर्क और / या आपके UI को System.Data.Elity से अलग करने की अनुमति देना है। इसके कई फायदे हैं, जिसमें इकाई परीक्षण में वास्तविक लाभ शामिल हैं, जिसमें वह फेक या मोक्स का उपयोग करने की अनुमति देता है।

— जेम्स कुलशव
स्रोत

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

— ब्रैंडन

एक और बात मैं बस जोड़ना चाहता था। हाँ CQRS MOST मामलों में एक बहुत ही बेहतर कार्यप्रणाली है। कुछ क्लाइंट्स के लिए मैंने उस समय काम किया है जब डेटाबेस लोग डेवलपर्स के साथ अच्छी तरह से काम नहीं करते हैं (जो कि विशेष रूप से बैंकों में एक से अधिक बार सोचते हैं) होता है, SQL पर EF सबसे अच्छा विकल्प है। उस विशिष्ट परिदृश्य में, जब आपके डेटाबेस पर आपका कोई नियंत्रण नहीं होता है, तो रिपॉजिटरी पैटर्न समझ में आता है। क्योंकि बारीकी से डेटा संरचना जैसा दिखता है और डेटाबेस पर जा रहे व्हाट्सएप और वाइस वर्सा का अनुवाद करना आसान है। मेरी राय में यह वास्तव में एक राजनीतिक और तार्किक निर्णय है। डीबी देवताओं को खुश करने के लिए।

— ब्रैंडन

1

मैं वास्तव में इस पर मेरी पिछली राय पर सवाल उठाने लगा हूं। ईएफ एक संयुक्त इकाई-ऑफ-वर्क और रिपॉजिटरी पैटर्न है। जैसा कि क्रिस प्रैट ने EF6 के साथ ऊपर उल्लेख किया है आप आसानी से प्रसंग और DbSet ऑब्जेक्ट का मजाक उड़ा सकते हैं। मेरा अभी भी मानना है कि वास्तविक डेटा एक्सेस तंत्र से व्यावसायिक तर्क वर्गों को ढालने के लिए डेटा एक्सेस को कक्षाओं में लपेटा जाना चाहिए, लेकिन पूरे हॉग पर जाने के लिए और ईएफ को एक और रिपॉजिटरी और यूनिट ऑफ़ वर्क एबस्ट्रेक्शन के साथ लपेटना अधिक कठिन लगता है।

— जेम्स कुलशॉ

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

— जोएल मैकबेथ

@jcmcbeth यदि आप मेरी टिप्पणी को सीधे अपने ऊपर देखते हैं तो आप देखेंगे कि मैंने रिपॉजिटरी पैटर्न और EF के संबंध में अपनी मूल राय बदल दी है।

— जेम्स कुलशॉ

0

हमें डुप्लिकेट लेकिन अलग-अलग एंटिटी फ्रेमवर्क DbContext के उदाहरणों में समस्याएँ आती हैं जब एक IoC कंटेनर जो कि नए () प्रकार के रिपॉजिटरी (उदाहरण के लिए एक UserRepository और एक GroupRepository उदाहरण है कि प्रत्येक DBContext से अपने स्वयं केbbet को कॉल करता है), कभी-कभी प्रति अनुरोध में कई संदर्भों का कारण बन सकता है। (एक एमवीसी / वेब संदर्भ में)।

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

— Mufasa
स्रोत

मैंने कई अलग-अलग परियोजनाओं में इस समस्या का सामना किया है।

— ColacX

0

छोटे प्रोजेक्ट पर रिपॉजिटरी पैटर्न आज़माने के बाद मैं इसे इस्तेमाल न करने की दृढ़ता से सलाह देता हूं; इसलिए नहीं कि यह आपके सिस्टम को जटिल बनाता है, और इसलिए नहीं कि डेटा का मजाक उड़ाना दुःस्वप्न है, बल्कि इसलिए कि आपका परीक्षण बेकार हो जाता है !!

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

वास्तविक डेटाबेस पर आपके परीक्षण को कम चलाने में आपको वास्तविक परिणाम मिलते हैं और आप न केवल अपनी सेवाओं और इंटरफेस बल्कि डेटाबेस व्यवहार का भी परीक्षण कर सकते हैं। आप जांच सकते हैं कि क्या आपकी संग्रहीत प्रक्रियाएं डेटा के साथ सही काम करती हैं, अपेक्षित परिणाम लौटाएं, या यह कि आपने जो रिकॉर्ड भेजा है वह वास्तव में हटा दिया गया है! इस तरह के परीक्षण भी ऐसे मुद्दों का पर्दाफाश कर सकते हैं जैसे संग्रहीत प्रक्रिया से त्रुटियों को उठाना, और हजारों ऐसे परिदृश्य।

मुझे लगता है कि अब तक पढ़े गए किसी भी लेख की तुलना में इकाई ढांचा रिपॉजिटरी पैटर्न को बेहतर तरीके से लागू करता है और यह उन चीजों से कहीं आगे निकल जाता है, जिन्हें वे पूरा करने की कोशिश कर रहे हैं।

रिपोजिटरी उन दिनों सबसे अच्छा अभ्यास था जहां हम XBase, AdoX और Ado.Net का उपयोग कर रहे थे, लेकिन इकाई के साथ !! (भंडार पर रिपॉजिटरी)

अंत में मुझे लगता है कि बहुत से लोग सीखने और रिपोजिटरी पैटर्न को लागू करने में बहुत समय लगाते हैं और वे इसे जाने देने से इनकार करते हैं। ज्यादातर खुद को साबित करने के लिए कि उन्होंने अपना समय बर्बाद नहीं किया।

— ज़ावर हारून
स्रोत

1

सिवाय इसके कि आप इकाई परीक्षणों में अपने डेटाबेस व्यवहार का परीक्षण नहीं करना चाहते हैं, क्योंकि यह पूरी तरह से परीक्षण का स्तर नहीं है।

— Mariusz Jamro

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

— क्रिस प्रैट

-3

माइग्रेशन के कारण इसकी: काम करने के लिए माइग्रेशन प्राप्त करना संभव नहीं है, क्योंकि कनेक्शन स्ट्रिंग वेब में रहता है ।config। लेकिन, DbContext रिपोजिटरी लेयर में रहता है। IDbContextFactory को डेटाबेस में कॉन्फ़िगरेशन स्ट्रिंग की आवश्यकता होती है। लेकिन ऐसा कोई तरीका नहीं है कि माइग्रेशन web.config से कनेक्शन स्ट्रिंग प्राप्त करता है।

चारों ओर काम कर रहे हैं, लेकिन मुझे अभी तक इसके लिए एक साफ समाधान नहीं मिला है!

— बिजली
स्रोत