रिपोजिटरी पैटर्न - एमवीसी स्टोरफ्रंट

Question

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

Answer 1

तर्क किसी भी तरह से बनाया जा सकता है, इस हाल के ब्लॉग पोस्टिंग देखें: Should my repository expose IQueryable?

Answer 2

IQueryable सामान कि रोब Conery MVC स्टोरफ्रंट में डाल दिया अभिनव है, लेकिन कोई आदर्श तरह से जब यह खजाने बनाने की बात आती है। आमतौर पर, एक डेटाबेस आपके डोमेन को डेटाबेस से मैप करने के लिए ज़िम्मेदार होता है। रिटर्निंग IQueryable वास्तव में कोई मैपिंग नहीं करता है और ऐसा करने के लिए सेवा परत पर निर्भर करता है। इसके फायदे और नुकसान हैं, लेकिन यह कहने के लिए पर्याप्त है कि यह करने का एकमात्र तरीका नहीं है।

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

Answer 3

सेवा परत में IQueryable को उजागर करने के साथ मेरे पास समस्या यह है कि यदि आप सर्विस लेयर कोड को तोड़ने के बिना किसी वेब सेवा के पीछे रिपोजिटरी परत को लपेटना चाहते हैं तो आप ADO.NET Data Services का उपयोग किए बिना नहीं कर सकते हैं, लेकिन फिर आपके सभी रिपोजिटरी कोड अनिवार्य रूप से अनावश्यक हो जाएगा।

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