MVC सिस्टम में, डेटाबेस दृढ़ता कोड कहां बैठना चाहिए?

21

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

नियंत्रक दृढ़ता का प्रबंधन करता है
मॉडल दृढ़ता का प्रबंधन करता है
थर्ड पार्टी लाइब्रेरी दृढ़ता का प्रबंधन करती है, आमतौर पर मॉडल पर कुछ प्रकार के एनोटेशन की आवश्यकता होती है।

मैं सोच रहा हूं कि कौन सा कॉन्फ़िगरेशन (यदि कोई है), अवधारणा के रूप में, उपयोग करने के लिए सबसे आसान / एक एमवीसी वास्तुकला के साथ सबसे अधिक अनुकूल है?

(यदि मैं इसे सूचीबद्ध नहीं करता, तो कृपया उत्तर के भाग के रूप में एक त्वरित रूपरेखा / अवलोकन दें)

mvc

— blueberryfields
स्रोत

13

आपके दूसरे और तीसरे विकल्प समान हैं। MVC में M डेटा मॉडल नहीं है, बल्कि डोमेन मॉडल है। इसमें दृढ़ता शामिल है, चाहे सीधे या ORM के माध्यम से, और दोनों पूरी तरह से सही हैं।

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

— PDR
स्रोत

2

मैं कुछ हद तक असहमत हूं। दृढ़ता का ठोस उपयोग अनुप्रयोग तर्क है और इस प्रकार एक आवेदन लेयर में है और डोमेन लेयर में नहीं है। डोमेन परत (डोमेन मॉडल युक्त) आकस्मिक व्यापार कार्यक्रम के लिए दृढ़ता से अनभिज्ञ होना चाहिए। नियंत्रक एक ऑर्केस्ट्रेटर है । यह (डेटा-) सेवाओं, यूआई और डोमेन मॉडल को ऑर्केस्ट्रेट कर सकता है।

— फाल्कन

1

@Falcon: नियंत्रक को नियंत्रित करना चाहिए जबकि जब डेटा से भरी हुई और डेटाबेस के लिए एक समान होती है, यह बिल्कुल ठीक है यह मॉडल बता ऐसा करने के लिए है। एक ORM (मानक या रोल-आपका-अपना) का उपयोग करने का मतलब आमतौर पर मॉडल को लोड करना / सहेजना होगा, जो तब ORM को दर्शाता है। एक अन्य तरीका यह हो सकता है कि नियंत्रक किसी ओआरएम को लोड करने / सहेजने के लिए कहे / इसे सहेजने के लिए एक मॉडल वर्ग को लोड करने के लिए (चयन मानदंड के साथ) या मॉडल उदाहरण को बचाने के लिए। किसी भी तरह से, वास्तविक लोडिंग / सेविंग को आदर्श रूप से मॉडल से जोड़ा जाएगा।

— मार्जन वेनमा

@ मार्जन वेनेमा: हां, मैं सहमत हूं, लेकिन सवाल यह है कि कोड कहां रहना चाहिए। मैं मॉडल को संभव के रूप में दृढ़ता से अनभिज्ञ रखने का प्रयास करता हूं और केवल अपने व्यवहार और बातचीत के साथ डोमेन संस्थाओं को मॉडल करता हूं। कुछ भी आवेदन परतों में रहेगा (क्योंकि यह मेरे मॉडल का एक अनुप्रयोग है)। मैपिंग की जानकारी / डेटा एक्सेस डोमेन मॉडल से पूरी तरह से डिकूप्ड है और वर्जनिंग (अपग्रेड / डाउनग्रेड) का भी ध्यान रख सकता है। डेटा एक्सेस का एप्लिकेशन एप्लीकेशन लेयर्स में भी रहता है (जिसमें सेवाएं, रिपॉजिटरी आदि शामिल हैं)

— फाल्कन

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

— मार्जन वेनमा

5

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

सेवा परत कई रूपों में से कोई भी ले सकती है, हालांकि मेरी व्यक्तिगत प्राथमिकता कुल जड़ संस्थाओं के लिए एक रिपॉजिटरी अमूर्त के साथ काम करना है, जिसके ठोस कार्यान्वयन या तो कुछ प्रकार के ORM, या एक हल्के DAO, या के साथ काम करेंगे। कुछ गैर-संबंधपरक स्टोर के लिए एपीआई यदि वह एप्लिकेशन के लिए समझ में आता है।

एक्टिव रिकॉर्ड पैटर्न का मतलब है कि आपके मॉडल में दृढ़ता की जिम्मेदारी है, हालांकि आमतौर पर इसका मतलब है कि कुछ प्रकार के आधार वर्ग आपके स्टोर में मैपिंग का प्रबंधन करते हैं, इसलिए आपका मॉडल वास्तव में सीधे शामिल नहीं है।

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

— JasonTrue
स्रोत

3

एमवीसी (मॉडल-व्यू-कंट्रोलर) प्रणाली में, मॉडल में डेटा होता है। इसलिए मेरा मानना है कि, डेटाबेस की दृढ़ता इसमें होनी चाहिए।

— Nettogrof
स्रोत

2

अधिकांश उच्च-स्तरीय MVC नमूने मैंने देखे हैं कि एक अलग infrastructureपरत है जिसमें वास्तविक डेटाबेस कार्यान्वयन कोड है (यानी NHibernate, या EF या Linq या जो भी आपके डेटा स्तर पर विशिष्ट कॉल है), जबकि "मॉडल" परत (अक्सर भी "डोमेन" परत में डेटा सेवाओं को परिभाषित करने वाले इंटरफेस हैं।

— वेन मोलिना
स्रोत

0

एमवीसी में मानक अभ्यास एम (ओडेल) परत में डेटा संरचना और दृढ़ता को शामिल करना है।

मॉडल परत में केवल वे कक्षाएं (POCOs आदि) शामिल नहीं हैं जिन्हें आप अपने एप्लिकेशन में उपयोग करने जा रहे हैं। उनमें उन वर्गों के लिए रिपॉजिटरी शामिल हैं।

एक उदाहरण एक रिपॉजिटरी होगा जहाँ आपके पास डेटा वर्गों के उदाहरण हैं, अर्थात:

Clients repository

AllClients()
RecentClients()
ClientByID(int id)

आप अपने मॉडल डोमेन के तरीके को बेहतर तरीके से व्यवस्थित कर पाएंगे, और आपके डेटा तक कई तरीकों से भी पहुंच बनाएंगे, लेकिन फिर भी डेटा / मॉडल की परत कॉम्पैक्ट और मजबूत होगी

— मुहालिस बागोस
स्रोत