वेब एप्लिकेशन डिज़ाइन करते समय CMS का उपयोग करने से ऑप्ट आउट करें

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

मैंने दोनों डिज़ाइन दृष्टिकोणों का वर्णन करने और जितना संभव हो उतना व्यापक रूप से प्रकट करने की कोशिश की, जो मैं खुद का उपयोग करता हूं।

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



सीएमएस के लाभ:

• कई डेवलपर्स द्वारा परीक्षण किया गया कोड
• चंचलता
• उपयोग में आसानी

सीएमएस के विपक्ष:

• विषय क्षेत्र उन वस्तुओं तक सीमित है जो सीएमएस में प्रदान की जाती हैं
• आवेदन का मुख्य तर्क सीएमएस के डेवलपर्स द्वारा निर्धारित किया जाता है। तर्क में परिवर्तन करना बहुत समस्याग्रस्त है
• अत्यधिक चंचलता (जिसके बिना सीएमएस स्वयं निरर्थक होगी) निरर्थक कार्यक्षमता की ओर ले जाती है

मुझे विषय क्षेत्र में काम करना क्यों पसंद है:

• यह अधिक स्पष्ट रूप से विषय क्षेत्र की वस्तुओं की बातचीत के तर्क का वर्णन करना संभव है
• आवेदन के तर्क को अधिक लचीले ढंग से बदलना संभव है
• क्लीनर कोड
• प्रदर्शन तर्क, डेटा प्रबंधन तर्क और व्यावसायिक तर्क अलग-अलग हैं

विषय क्षेत्र के साथ काम करने के नुकसान

• शुरू में प्रोजेक्ट बनाने में अधिक समय लगता है
• कुछ चीजें हाथ से लिखी जानी चाहिए
• ऊपर डेवलपर की योग्यता

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

वेब एप्लिकेशन आर्किटेक्चर विकल्प उपलब्ध हैं

नीचे मैं सीएमएस का उपयोग करके और डोमेन-आधारित डिज़ाइन दृष्टिकोण का उपयोग करके निर्मित वेब अनुप्रयोगों के आर्किटेक्चर के एक सामान्यीकृत संस्करण का वर्णन करूंगा।

सामान्य वेब अनुप्रयोग वास्तुकला सीएमएस का उपयोग करना

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

सामान्य डोमेन मॉडल-आधारित वेब अनुप्रयोग वास्तुकला

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

जीवन से कुछ सीमाएँ और अनुभव

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

• पृष्ठ मेटाडेटा का आरंभ (कीवर्ड, विवरण)
• विहित url सेट करना
• ओपन ग्राफ के लिए डेटा आरंभीकरण (फेसबुक, Vkontakte)
• ईमेल भेजना
• क्वेरी पैरामीटर की सुरक्षित पुनर्प्राप्ति (साधारण यूआरएल से पैरामीटर, या रूटिंग का उपयोग करने वाले यूआरएल उसी तरह से प्राप्त किए जाते हैं, पहले से ही टाइप के साथ)
• अपवाद से निपटने
• इंटरफ़ेस पीढ़ी (उदाहरण के लिए, डायनामिक डेटा - विशेष रूप से संसाधन प्रशासन के लिए उपयोग किया जाता है)

इस प्रकार, एक नया एप्लिकेशन डिजाइन करते समय, मैं विरासत में मिली कार्यक्षमता पर भरोसा कर सकता हूं, लेकिन साथ ही मैं एक विदेशी वास्तुकला से बंधा नहीं हूं।

निष्कर्ष

विभिन्न अवलोकनों के आधार पर, मैं कह सकता हूं कि सीएमएस का उपयोग करते हुए एक परियोजना के विकास की कुल लागत सक्रिय रूप से विकसित हो रही है (अर्थात, नई कार्यक्षमता अक्सर दिखाई देती है) विषय क्षेत्र के आधार पर तैयार की गई परियोजना की तुलना में अधिक होगी।

इसका मतलब यह नहीं है कि सीएमएस की जरूरत नहीं है। उन्हें जरूरत है, और कई मामलों में ऊर्जा, समय और धन की बचत होती है। लेकिन अगर परियोजना "होम पेज" से अलग है - सबसे अधिक संभावना है कि विषय क्षेत्र को ध्यान में रखते हुए डिजाइनिंग अधिक प्रभावी होगी।