सिस्टम को डिजाइन करते समय, क्या आपके द्वारा उपयोग किए जा रहे ढांचे के आसपास डिजाइन को पूरा करना सबसे अच्छा अभ्यास है?

Question

जब आप एक निश्चित ढांचे के साथ उपयोग करने की योजना बनाते हैं, तो एक प्रणाली विकसित करना, क्या फ्रेमवर्क को ध्यान में रखे बिना सिस्टम को डिजाइन करना सबसे अच्छा अभ्यास है, या क्या सिस्टम को मानसिकता के साथ डिजाइन करना बेहतर है "अच्छी तरह से फ्रेमवर्क का एक आसान समय होगा। इसके साथ"।

Comments

आप किस तरह के ढांचे की बात कर रहे हैं? क्या आपके पास कुछ आला व्यापार-विशिष्ट ढांचे का मतलब है जो किसी विशेष उद्योग के लिए बहुत ही डोमेन-विशिष्ट समस्याओं को हल करने के लिए डिज़ाइन किया गया है? (जैसे चिकित्सा, परमाणु, रक्षा, विमानन, आदि)। या आप तकनीकी समस्याओं को हल करने के लिए डिज़ाइन किए गए सामान्य प्रयोजन के फ्रेमवर्क के बारे में बात कर रहे हैं?

— बेन कॉटरेल

तकनीकी समस्याओं को हल करने के लिए डिज़ाइन किए गए सामान्य-प्रयोजन के ढांचे

— रॉबर्ट पाउंडर

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

— रॉबर्ट पाउंडर

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

— स्टैनियस

पहिए वाले सार्वजनिक पारगमन वाहन को डिजाइन करने की कोशिश में खो जाने के दौरान बस से टकरा जाना बहुत बुरा होगा।

Answer 1

आपके डिज़ाइन को ग्राहकों की ज़रूरतों को पूरा करना चाहिए जितना वे कर सकते हैं। याद रखें कि डिजाइन में छोटी चीजें शामिल हैं जैसे:

• प्रयोगकर्ता का अनुभव
• कार्यक्षमता
• आपके एप्लिकेशन के टुकड़े कैसे संवाद करते हैं (या तो स्वयं या बाहरी संस्थाओं के साथ)

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

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

संक्षेप में

• अपने उपयोगकर्ताओं के लिए डिज़ाइन करें
• अपने डिजाइन को पूरा करने के लिए उपयुक्त उपकरण चुनें
• अपने औजारों का उपयोग करें जिस तरह से वे उपयोग करने के लिए डिज़ाइन किए गए हैं

---

आगे के विचार:

सॉफ्टवेयर इंजीनियरिंग के 20+ वर्षों के बाद, और कई चौखटे का उपयोग करके, मैंने कुछ सबक सीखा है। सभी चौखटे एक दोधारी तलवार हैं: वे दोनों को विवश और सक्षम बनाते हैं। इससे पहले कि मैं ऊपर बताए गए बड़े 3 को देखने के लिए अपना ढांचा तय करने के साथ मुद्दा यह है कि आप एक औसत दर्जे के लिए एक अच्छे उपयोगकर्ता अनुभव से समझौता कर सकते हैं (सबसे अच्छा) एक। या आप कुछ विशिष्ट कार्यक्षमता को पूरा करने के लिए चौखटे डिजाइन से विचलित करने के लिए मजबूर हो सकते हैं।

Comments

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

— बेरिन लोरिट्श

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

— गुस्सोर

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

— लैविस

@Laiv बढ़िया टिप्पणी! वास्तव में, यह "कुछ और कुछ" है। एक नेलगन और एक स्क्रूगन दोनों सामान को जकड़ सकते हैं, एक दूसरे की तुलना में अधिक प्रतिवर्ती है और धीमी गति से भी काम करता है और अधिक जटिल है। लोगों की पसंद का हर विकल्प अपरिहार्य रूप से एक व्यापार है। आप अपने पैसे का भुगतान करते हैं और आप अपने अवसरों को लेते हैं।

@RobertPounder, यह एक उपकरण है जो एक समाधान के लिए उपयुक्तता को सिस्टम को डिज़ाइन करते समय तय किया जाना चाहिए । मैं समझता हूं कि फ्रेमवर्क डिजाइन को कैसे प्रभावित कर सकता है, लेकिन उन्हें इसे निर्देशित नहीं करना चाहिए।

— बेरिन लोरिट्श

Answer 2

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

अधिक व्यापक रूप से, आपको किसी भी एकल ढांचे या तकनीक को अपने पूरे सिस्टम आर्किटेक्चर के "बड़े चित्र" को निर्देशित या संचालित करने से बचना चाहिए। अधिकांश सामान्य-उद्देश्य वाले एप्लिकेशन फ्रेमवर्क इसे प्रोत्साहित नहीं करते हैं, इसलिए यदि आप अपने आप को एक फ्रेमवर्क के आसपास अपना पूरा सिस्टम लिखते हुए पाते हैं तो आप शायद कुछ कर रहे हैं, उस फ्रेमवर्क के लेखक का इरादा नहीं था।

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

सामान्य प्रयोजन के ढांचे (जैसे कि यूआई फ्रेमवर्क, डेटा लेयर फ्रेमवर्क, आदि) आपके सिस्टम की पूरी वास्तुकला को संरक्षित करने के लिए मौजूद नहीं हैं - कम से कम वे एक घटक या मॉड्यूल के डिजाइन को लिख सकते हैं; उदाहरण के लिए, कुछ GUI प्रौद्योगिकियाँ विशेष रूप से MV * प्रतिमानों के अनुरूप हैं।

आपके सिस्टम की समग्र वास्तुकला मुख्य रूप से आपकी व्यावसायिक आवश्यकताओं से प्रेरित होनी चाहिए । किसी चीज़ को आपस में बाँधने के लिए आप किसी विशेष टूल (उदाहरण के लिए, एक संदेशवाहक मिडलवेयर टूल, या ORM फ्रेमवर्क) पर खुद को बहुत अधिक झुका पाते हैं, लेकिन यदि आपने एक 'सर्विस' क्लास जैसे एब्स्ट्रक्शन में फ्रेमवर्क को एनकैप्सुलेट किया है जब आप अपनी सीमाओं का सामना करते हैं तो उस ढांचे से खुद को विवश होने की संभावना कम होती है।

अपने बड़े-चित्र डिजाइन के लिए निम्नलिखित बातों को ध्यान में रखने की कोशिश करें:

• मॉड्यूलर सॉफ्टवेयर का निर्माण करना
• प्रत्येक मॉड्यूल और घटक लिखते समय चिंताओं के पृथक्करण पर विचार करें
• सिस्टम को परतों में अलग करने के लिए मल्टी-टीयर आर्किटेक्चर पर विचार करें
• लीक के सार का निर्माण न करें
• इस संबंधित सवाल पर acronyms : क्या सूखी, KISS, ठोस, आदि के रूप में वर्गीकृत कर रहे हैं?

Comments

कभी-कभी ऐसा लगता है कि कुछ फ्रेमवर्क लेखकों को अपने उपयोगकर्ताओं को कोड कोड को कसकर लिखने की ज़रूरत नहीं है।

— से आया

@COMEFROM - अपने कोड को ढांचे में कसने से डेवलपर्स को प्रोत्साहन मिलेगा क्योंकि वे मानते हैं कि आपने उन्हीं समस्याओं को हल करने के लिए अपना ढांचा चुना था, जिन्हें उन्होंने पहली बार में तैयार किया था।

— जेएफओ

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

— रॉबर्ट पाउंडर

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

— बेन कॉटरेल

मुझे यहाँ @nocomprende से असहमत होना चाहिए; भविष्य की सभी आवश्यकताओं की भविष्यवाणी नहीं की जा सकती है, लेकिन कभी-कभी सिस्टम को केवल इसलिए फिर से लिखा जाता है क्योंकि पिछले सॉफ़्टवेयर का विस्तार / रखरखाव करना बहुत मुश्किल है ।

— सेलेडमनीडे

Answer 3

हां, आपको जितना संभव हो उतना करीब से रहना चाहिए ।

कारण बस इतना है कि आप "सोच" के चौखटे के करीब रहते हैं, उतनी ही आसानी से आप अन्य डेवलपर्स से अपनी समस्याओं / विचारों के बारे में बात कर पाएंगे, जो उस ढांचे का उपयोग भी करते हैं।

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

एकमात्र अच्छा कारण मैं यह सोच सकता हूं कि आप फ्रेमवर्क को "क्यों" तोड़ देंगे, आपको इसकी "डिफ़ॉल्ट" कॉन्फ़िगरेशन / सिद्धांतों के आवेदन प्रदान नहीं कर सकते हैं। लेकिन फिर, यह शुरू करने के लिए सही ढांचा नहीं हो सकता है।

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

Comments

हो सकता है कि आपको प्रश्न के परिवर्तनों के कारण अपने उत्तर की समीक्षा करनी चाहिए। आपका जवाब वास्तव में ओपी के सवाल का जवाब नहीं देता है।

— लैव

@Laiv मैं यह नहीं देखता कि यह प्रश्न का उत्तर कैसे देता है, यद्यपि यह विषय पर आपकी राय से मेल नहीं खा सकता है, फिर भी यह एक उत्तर है। प्रश्न में विषय की परस्पर विरोधी प्रकृति को प्रदर्शित करने के लिए अपना जवाब लिखने के लिए आपका स्वागत है।

— एफपी

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

— लैव

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

आपके डिज़ाइन को इस बात को प्रभावित करना चाहिए कि आप किस फ्रेमवर्क को चुनते हैं (यदि कोई हो!), दूसरे तरीके से नहीं।

— रबरडक