ASP.NET WebForms अनुप्रयोग के लिए सर्वश्रेष्ठ वास्तुकला

Question

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

कार्यक्षमता

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

वर्तमान वास्तुकला

यह वर्तमान में डेटाबेस को पढ़ने / लिखने के लिए EF4 का उपयोग कर रहा है। EF ऑब्जेक्ट्स का उपयोग सीधे aspx फ़ाइलों के भीतर किया जाता है। जब मैंने साइट लिखी है तो इसने तेजी से विकास किया है लेकिन संभवतः इसे इस तरह से रखना अस्वीकार्य है क्योंकि यह UI के साथ db को कसकर युग्मित कर रहा है। विशिष्ट व्यावसायिक तर्क को EF ऑब्जेक्ट्स के आंशिक वर्गों में जोड़ा गया है।

प्रशन

रिफैक्टरिंग का लक्ष्य साइट को स्केलेबल, आसानी से बनाए रखने योग्य और सुरक्षित बनाना होगा।

1. इसके लिए किस तरह की वास्तुकला सबसे अच्छी होगी? कृपया वर्णन करें कि प्रत्येक परत में क्या होना चाहिए, क्या मुझे DTO / POCO / सक्रिय रिकॉर्ड पैटर्न आदि का उपयोग करना चाहिए

2. क्या डीटीओ / बीओ को ऑटो-जेनरेट करने का एक मजबूत तरीका है ताकि अतिरिक्त परतों के बावजूद भविष्य में किसी भी एन्हांसमेंट को लागू करना आसान हो?

3. क्या WebForms से MVC में प्रोजेक्ट को बदलना फायदेमंद होगा?

Comments

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

— गहोआ

अपनी वर्किंग प्रोजेक्ट तकनीक को नई xyz तकनीक में सिर्फ इसलिए न बदलें क्योंकि यह वहां है, विशेष रूप से तब जब आपका प्रोजेक्ट ठीक काम कर रहा हो। अगर यह काम कर रहा है तो इसे न तोड़े। व्यवसाय कोड की परवाह नहीं करता है। कार्यात्मकता वह सब है जो दिन के अंत में मायने रखती है।

— NoChance

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

— स्टैक मैन

अभी भी गन्दा लगता है: 1) UI में EF ऑब्जेक्ट्स (UI परत में फ़ाइलों के पीछे कोड)

— स्टैक मैन

(2) विस्तारित EF ऑब्जेक्ट्स में व्यावसायिक तर्क जो DAL लेयर में जाने थे (महसूस नहीं किया गया था कि आंशिक कक्षाएं एक ही असेंबली में होनी चाहिए) (3) UI लेयर में aspx.cs फ़ाइलों के भीतर बिजनेस लॉजिक। हालांकि, ऐसा लगता है कि वास्तुकला की बात आती है तो अक्सर समझौते होते हैं लेकिन यह निश्चित रूप से एक कदम आगे है। मुझे लगता है कि यह पहली रिलीज के लिए स्वीकार्य है और जैसे-जैसे समय आगे बढ़ेगा हम अपने दृष्टिकोण पर भरोसा कर सकते हैं। आप सबकी मदद के लिए धन्यवाद। इस क्षेत्र का इतना व्यक्तिपरक होना थोड़ा अच्छा है।

— स्टैक मैन

Answer 1

ASP.NET MVP पैटर्न लंबे समय तक ASP.NET वेबफॉर्म एप्लिकेशन के लिए सबसे अच्छा आर्किटेक्चर है । यह "चिंताओं को अलग करने" की अवधारणा के साथ चल रहा है, जो एमवी * पैटर्न के पीछे की प्रवृत्ति है।

क्यों इसका इस्तेमाल करने पर सवाल ? - इस पोस्ट में विवरण में संबोधित किया गया - ASP.NET MVP

• ASP.NET वेबफॉर्म एप्लिकेशन के परीक्षण के साथ आरंभ करना
• MVP बनाम MVC के बीच व्यापार-नापसंद
• भ्रम की समाप्ति: एमवीपी बनाम एमवीसी

Comments

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

— स्टैक मैन

खैर, यह एक एमवीपी (मॉडल-व्यू-प्रस्तोता) पैटर्न है और एमवीसी (मॉडल-व्यू-कंट्रोलर) नहीं है।

— युसुबोव

ओह सॉरी - मुझे गलत लगा। धन्यवाद - मैं एमवीपी डिजाइन के बारे में पढ़ूंगा।

— स्टैक मैन

कोई बात नहीं, मुझे आशा है कि आप वही पाएंगे जो आप खोज रहे हैं :)

— युसुबोव

ऐसा लगता है कि एमवीपी में परिवर्तित करना भी एक बड़ा बदलाव होगा। क्लाइंट बहुत जल्द जारी करना चाहता है, तो क्या आपको लगता है कि उपरोक्त वास्तुकला डीएएल / डीए / यूआई (हालांकि एमवीपी के रूप में आदर्श नहीं है) इस प्रकार के आवेदन के लिए स्वीकार्य होगा? फिर रिलीज़ होने के बाद हम v2 में MVP के लिए आगे बढ़ सकते हैं।

— स्टैक मैन

Answer 2

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

Comments

यकीन नहीं होता कि किसी ने भी इस सवाल को क्यों नहीं टाल दिया। सच कहूं, तो यह सबसे संक्षिप्त जवाब है। +1

— ग्रेग बर्गार्ड्ट

Answer 3

जैसा कि एल्युसुबोव ने उल्लेख किया है, एमवीपी पैटर्न महान हो सकता है।

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

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

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

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

संपादित करें

आपने एक व्यावसायिक तर्क वर्ग के वारिस के पीछे कोड होने के बारे में पूछा। ऐसा नहीं किया जा सकता क्योंकि "पीछे-पीछे" कोड एक पृष्ठ है। C # एकाधिक वंशानुक्रम की अनुमति नहीं देता है, इसलिए कोड-पीछे वर्ग एक पृष्ठ और एक कस्टम ऑब्जेक्ट दोनों नहीं हो सकता है। आपको तार्किक रूप से तर्क को अलग करने की आवश्यकता है। शायद यह मामला है कि आपके कोड-पीछे में कोड कई अलग-अलग चीजें कर रहा है। एक वर्ग को एक काम और एक ही काम करना चाहिए। कोशिश करें और सोचें कि आप मौजूदा कार्यक्षमता को कैसे वैचारिक रूप से खींच सकते हैं। उदाहरण के लिए, आपको बताएंगे कि आपके पास एक पंजीकरण पृष्ठ है और आप उपयोगकर्ता जानकारी एकत्र कर रहे हैं। आपके पास संभवतः रजिस्टर नाम का एक बटन और उस बटन के साथ जुड़े एक क्लिक घटना है। उस घटना में आप उपयोगकर्ता की जानकारी सहेज रहे हैं और आपको जो भी प्रसंस्करण की आवश्यकता है वह कर रहे हैं। आप उस सभी तर्क को संभालने के लिए एक पंजीकरण ऑब्जेक्ट बना सकते हैं।

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

यदि आप एमवीपी पैटर्न का सख्ती से पालन करना चाहते हैं, तो पंजीकरण ऑब्जेक्ट को पैरामीटर पारित करने के बजाय कोड-पीछे एक इंटरफ़ेस लागू करेगा। इंटरफ़ेस का कार्यान्वयन अनिवार्य रूप से सभी दृश्य वस्तुओं (टेक्स्ट फ़ील्ड आदि) को इंटरफ़ेस में मैप करेगा। उदाहरण के लिए सार्वजनिक स्ट्रिंग FirstName {get {रिटर्न txtFirstName.Text; }}

एक बार ऐसा हो जाने के बाद आप पेज को Regisration ऑब्जेक्ट में पास कर सकते हैं

Registration.RegisterUser (this);

और यह RegisterUser विधि इंटरफ़ेस को एक पैरामीटर के रूप में ले जाएगा

सार्वजनिक बूल पंजीकरणकर्ता (IUser उपयोगकर्ता) {user.FirstName ...}

सार्वजनिक इंटरफ़ेस IUser {सार्वजनिक स्ट्रिंग FirstName; }

यदि यह एमवीपी भ्रामक लगता है, तो केवल रिफैक्टरिंग पर ध्यान केंद्रित करें और पता करें कि यह सब कोड-पुन: उपयोग को अधिकतम करना है। खुद को दोहराने के बाद से कोई नहीं है। वह डीआरवाई प्रिंसिपल है ।

Comments

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

— ढेर आदमी

मैं अपने जवाब में आपकी टिप्पणी का जवाब दूंगा। बेझिझक मेरे उत्तर को अपवित्र करें यदि आपको यह उपयोगी लगे

— कोडर