आप इस एप्लिकेशन को कैसे मॉडल करेंगे?

Question

मैं एक MVC आवेदन Zend फ्रेमवर्क है कि एक Oracle 10g डेटाबेस और प्रदर्शित करता है टेबल्स और सूचियों में इस डेटा से डेटा खींचती है और नेत्रहीन रंग और चार्ट के माध्यम से इस डेटा समृद्ध के साथ लिखा मिल गया है। कोई ओआरएम नहीं है और कोई भी बनाएँ, अपडेट या हटाएं, केवल शुद्ध पठन। डेटा किसी अन्य एप्लिकेशन से डाला गया है। डीबी में डेटा अवधारणाओं वे प्रतिनिधित्व के बाद मॉडलिंग की और करके डीबी विचार है कि विभिन्न अन्य तालिकाओं से इस डेटा को समेकित (विरासत, बदल नहीं सकते), उदा एक्सेस किया जाता है

| Event ID | Start    | End     | Status | Created_By | 
----------------------------------------------------------------------------- 
| 12345678 | 2009-10-01 12:00:00 | 2009-10-01 12:15:00 | booked | John Doe | 
| 12345679 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | booked | John Doe | 
| 12345680 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | tba | Jane Doe | 

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

मेरे वर्तमान दृष्टिकोण इस तरह मोटे तौर पर काम करता है:

Request --> Controller 
      | <--> sanitizes and returns Request params 
      | ---> Facade (capsules steps to fetch View Data) 
      |  | <--> Table Data Gateway builds Query for requested View 
      |  | <--> Query Decorator¹ applies User/Client settings 
      |  | <--> DB Adapter fetches RecordSet from decorated Query 
      | <----returns Recordset 
      | <--> applies RecordSet to View 
      | <--> Data-Aware ViewHelper render RecordSet (and View) 
Response <--returns rendered View 

¹क्वेरी डेकोरेटर मौजूदा उपयोगकर्ता/ग्राहक सेटिंग्स में पढ़ सकते हैं और मक्खी पर TDG द्वारा दिया बुनियादी क्वेरी वस्तु में जोड़ सकते हैं।

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

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

नोट
मैं एक जवाब स्वीकार करने से पहले पूरी अवधि के लिए खुला प्रश्न छोड़ देंगे। किसी भी इनपुट की सराहना की है।

Answer 1

अपने प्रश्न कई बार फिर से पढ़ रहे हैं और एक बिट के लिए उस पर परिलक्षित करती है के बाद, मेरा मानना ​​है कि मैं thusly स्थिति योग होगा:

"एम" अपने "MVC" से लापता है।

इस बिंदु पर, आपने एक रिलेशनल डेटाबेस स्कीमा को हाथ से तैयार किया है जैसे कि आपके डोमेन मॉडल के साथ 1: 1 मैपिंग है। और यह बढ़िया है, यह मैपिंग को बहुत आसान बनाता है, लेकिन एक रिकॉर्डसेट अभी भी एक डोमेन क्लास नहीं है। MVC के संदर्भ में

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

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

वास्तुकला के मेरे संस्करण इस प्रकार दिखाई देगा:

Request --> Controller 
      | <--> sanitizes and returns Request params 
      | ---> Facade (encapsulates steps to fetch View Data) 
      |  | <--> Table Data Gateway builds Query for requested View 
      |  | <--> Query Decorator applies User/Client settings 
      |  | <--> DB Adapter fetches RecordSet from decorated Query 
***   |  | <--> Mapping layer converts RecordSet to Domain Model 
***   | <----returns Model 
***   | <--> applies Model to View 
***   | <--> Data-Aware ViewHelper render Model (and View) 
Response <--returns rendered View 

मैं *** साथ बदलाव लाइनों में चिह्नित किया है। असल में, केवल एक चीज जो मैंने बदल दी है वह है कि अग्रभाग से एक रिकॉर्ड सेट चुनने के बजाय, यह एक मॉडल (संभवतः डोमेन कक्षाओं की एक सरणी) उठा रहा है, और को दृश्य में लागू कर रहा है।

अपने दृश्य [हेल्पर] में $row['Status'] जैसे शब्दों के बजाय, आपके पास $event->status होगा, जो लंबी अवधि तक बनाए रखने के लिए सुरक्षित और सरल है। वहां कोई कॉलम नाम नहीं है, बस एक संपत्ति है।

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

ये सभी बातें कारण है कि आप एक डोमेन मॉडल है, कारण है कि यह वास्तव में MVC के मौलिक निर्माण खंड है: अंत में, मानसिक मॉडल अपने उपयोगकर्ताओं होगा डाटा मॉडल से तालमेल न बिठा गिरावट, कई कारणों से मैं यहां नहीं पहुंचूंगा। मुद्दा यह है कि यह लगभग हमेशा होता है।

क्या मुझे यकीन है कि यह आवश्यक है? क्या मैं सकारात्मक हूं कि यह सिर्फ इतना ही नहीं है, अनुष्ठानों का एक समूह है जिसका इस तरह की एक छोटी परियोजना के लिए कोई अर्थ नहीं है?

नहीं, मैं नहीं हूं। केवल आप ही तय कर सकते हैं। मैं बता सकता हूं कि एमवीसी प्रतिमान विशिष्ट आर्किटेक्चर उचित डोमेन मॉडल के बिना आपको बहुत अच्छा नहीं कर रहा है। यह थोड़ा बेहतर है, लेकिन नहीं है कि प्रत्येक पृष्ठ में केवल इनलाइन पूछताछ या मुखौटा कॉल करने से कहीं बेहतर है। एक मॉडल के बिना, एमवीसी एक फैंसी यूआरएल-रीराइटिंग योजना से कहीं ज्यादा नहीं है।

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

आशा है कि यह वह उत्तर है जिसे आप ढूंढ रहे थे!

Answer 2

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

एक बुरे उदाहरण के रूप में मुझे 'ओरेकल फॉर्म' का उपयोग करके एक एप्लिकेशन याद है, जो सीधे डेटाबेस संरचना से एक सामान्य दृश्य प्रस्तुत कर रहा था। गैर-तकनीकी लोगों के लिए यह अक्सर उपयोग करने के लिए बहुत प्रतिद्वंद्वी था।

फिर भी मैं आपके मामले में सोचता हूं, अगर दृश्य सीधे डीबी स्कीमा में मैप किया जा सकता है, तो निश्चित रूप से अनावश्यक abstraction-layers, कोड से छुटकारा पाएं और सिस्टम को सरल बनाएं। जितनी सरल हो सके उतनी सरलताओं को लागू करें।

Answer 3

उपयोगकर्ता इनपुट के आधार पर तालिका से गतिशील रूप से डेटा प्राप्त करने के लिए आप Zend_Dojo घटक डेटा ग्रिड का उपयोग कर सकते हैं। आप एक टीडीजी ऑब्जेक्ट बना सकते हैं जो उपयोगकर्ता इनपुट के आधार पर नई तालिका में रीमेप करेगा।

http://zendguru.wordpress.com/2009/01/08/dojo-grid-in-zend-framework-creating-nice-and-cool-grid-in-php-using-zend-framework-and-dojo/