2009-04-08 10 views
6

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

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

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

जोड़ा गया: मिले this somewhat related question

जोड़ा गया 2: ठीक है, ऐसा लगता है कि यदि पर्याप्त प्रस्तुति-संबंधी मेटाडेटा उपलब्ध है एक तरह से यह बहुत उचित परिणाम प्राप्त कर सकते है। इस दृष्टिकोण के लिए, "पर्याप्त" कितना होगा, और यह मैन्युअल रूप से फ़ॉर्म को डिजाइन करने से कम काम करेगा? क्या यह भविष्य के बदलावों के लिए अधिक लचीलापन भी प्रदान करता है?

+0

यदि आपके पास कोई समस्या नहीं है, तो http://subsonicproject.com/ –

+0

पर नज़र डालें, नहीं, मैंने नहीं किया है। धन्यवाद! मैं इसे देख लूँगा। –

उत्तर

5

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

सब कुछ हमारे लिए अच्छा काम करता है। दुर्भाग्य से यह एक बेचा बैंकिंग उत्पाद है और कोई उपलब्ध स्रोत नहीं है।

+1

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

+0

ऐसा करने के लिए आपको यूआई के लिए एक प्रकार का अबास्ट्रक्शन चाहिए जहां UI को विशिष्ट क्षेत्रों, प्रकारों, शैली - उस तरह की चीज़ों में परिभाषित किया गया है। गुण विस्तृत नहीं थे। हमने एक ग्रिड प्रकार के डिस्प्ले पर काम किया ताकि वे अधिक पसंद कर सकें, हालांकि किस प्रकार (हालांकि इस प्रकार का अधिकांश समय अनुमान लगाया गया था) ... –

+0

लेकिन अगर आप इस प्रकार को बदलना चाहते थे (ui प्रकार मेरा मतलब) और यह भी सत्यापन यहां परिभाषित किए गए थे (अनिवार्य, रेगेक्स, न्यूमेरिक, मुद्रा, आदि ...), दृश्यता, वे किस समूह से संबंधित हैं (हमारे पास उपशीर्षक (ढहने योग्य) जैसे एमएस पैसे थे) आदि ... –

0

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

मैं सामान की इस तरह के लिए मेटा डेटा के संरक्षण के लिए एक्सएमएल का इस्तेमाल किया है में एक डिजाइनर प्रपत्र का उपयोग करने के लिए अपने ui जैसा चाहें अनुकूलित कर सकते हैं।गुण जो मैं हर क्षेत्र के लिए सहेज कर के कुछ थे:

  1. FriendlyName (लेबल कैप्शन)
  2. haspredefinedvalues ​​(हाँ ड्रॉप डाउन सूची/मल्टी चेक बॉक्स सूची के लिए)
  3. एकाधिक चयन करें (हाँ तो बॉक्स को चेक करते सूची, अगर नहीं तो ड्रॉप डाउन सूची)
  4. डेटाप्रकार
  5. maxlength
  6. आवश्यक
  7. MINVALUE
  8. MAXVALUE
  9. रेग्युलर ऍक्सप्रैशन
  10. सक्षम (दिखाने के लिए या दिखाने के लिए नहीं)
  11. sortkey (वेब ​​फार्म पर आदेश)

के बारे में स्थिति - मैं ज्यादा परवाह नहीं और बस उत्पन्न टेबल टी टीडी टैग 1 अन्य के नीचे - हालांकि यदि आप इसे भी कार्यान्वित करना चाहते हैं, तो आपके पास CssClass नामक 1 और विशेषता हो सकती है, जहां आप ui विशिष्ट गुण (देखें और महसूस, स्थिति, आदि) को परिभाषित कर सकते हैं

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

मैं भी आप की सिफारिश Entity-attribute-value model को देखने के लिए चाहते हैं के माध्यम से जिम्मेदार बताते हैं - यह अपने आप ही पक्ष-विपक्ष है, लेकिन मैं बहुत अच्छी तरह से यह किया जा सकता है महसूस हो रहा है आपकी आवश्यकताओं के साथ।

4

यह कुछ छोटे के लिए ठीक है, जहां सभी की जरूरत में डेटा प्राप्त करने के लिए एक उपयोगी तरीका है।

हालांकि कोई वास्तविक आवेदन जैसी किसी चीज़ के लिए, यह एक भयानक विचार है। एक अच्छा यूआई के लिए क्या बनाता है मानवता कारक है, बिट्स जो आप यह सुनिश्चित करने के लिए चिल्लाते हैं कि यह मशीन किसी व्यक्ति के स्पर्श के लिए अच्छी तरह से प्रतिक्रिया करती है।

आप तब नहीं प्राप्त कर सकते जब आपका इंटरफ़ेस यांत्रिक रूप से जेनरेट किया गया हो .... शायद एआई के करीब कुछ के साथ। :)

संपादित करें - स्पष्टीकरण के लिए: कोड/डीबी से उत्पन्न यूआई एक शुरुआती बिंदु के रूप में ठीक है, यह सिर्फ एक बकवास अंत बिंदु है।

+1

यह मूल राय है जो मैंने सुना था। और सहजता से यह वास्तव में ऐसा लगता है, मैं कुछ उदाहरणों को स्वीकार या अस्वीकार करना चाहता हूं। :) –

+1

मुझे नहीं लगता कि यह सच है।यह हमारे लिए पूरी तरह से काम करता है और हमारे ग्राहक उपयोगिता के साथ पूरी तरह से खुश थे। क्या आपके पास असली दुनिया परिदृश्य है जहां यह अच्छा नहीं है, या यह सिर्फ एक राय है? –

+0

बस स्पष्ट करने के लिए हमने बहुत कुछ किया और फिर डेटाबेस को उत्पन्न कर दिया। बहुत सारे मेटाडाटा (कटोम विशेषताओं का उपयोग करके) का उपयोग किया गया था। –

0

वहाँ मेरी राय कुछ चीजें आप के बारे में सोचना चाहिए:

  1. ग्राहक अपने यूआई अनुकूलित करने के लिए एक समारोह की आवश्यकता है?
  2. क्या कई अलग-अलग गुण या तत्व हैं?
  3. क्या इस तरह के "प्रतिपादन इंजन" को बनाने का प्रयास है?

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

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

0

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

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

+0

ठीक है, मैं सीधे डीबी की तुलना में कुछ व्यावसायिक वस्तुओं को प्रदर्शित करने की सोच रहा था। उपयोगकर्ता को टेबल प्रदर्शित करना वास्तव में काम करने का एक बहुत साफ तरीका नहीं है ... मुझे लगता है ... फिर फिर, लोग एक्सेल से प्यार करते हैं, है ना? –

+0

या वे वास्तव में करते हैं? :) – haqwin

0

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

+0

Ermm ... ठीक है, सबसे पहले, मैं इस तथ्य पर आपका ध्यान रखना चाहता हूं कि यह प्रश्न 4 साल से अधिक पुराना है और चर्चा पहले से ही काफी पुरानी है। वैसे भी, मेरा विचार था कि सीआरयूडी अनुप्रयोग डेवलपर्स के रूप में हम जो भी काम करते हैं, वह फॉर्म डिज़ाइन समेत काफी दोहराया जाता है। निश्चित रूप से अब और फिर एक विषमता है, लेकिन अधिकांश भाग के लिए यह वही सामान बार-बार होता है। मेरा सवाल था - क्या इसके कुछ (सबसे?) को स्वचालित करना संभव होगा। इस मामले में, यूआई, जिसमें हमेशा एक ही तत्व होते हैं, अलग-अलग रूपों में अलग-अलग नाम होते हैं। –

+0

वैसे भी, 4 साल से मैंने इस प्रश्न को पोस्ट करने के बाद से अपने विचारों को भी बदल दिया है। आज मैं इसे पुस्तकालय द्वारा हल करने का प्रयास करूंगा जो अधिकांश मानक मामलों को कवर करता है। इस तरह दोहराव की सामग्री कम से कम हो जाती है, जबकि असाधारण मामलों द्वारा लचीलापन की अनुमति भी मिलती है। –

संबंधित मुद्दे