एक वेब पेज की तुलना में अन्य परियोजनाओं पर System.Web जोड़ रहा है एक बुरा अभ्यास?

Question

मैं अपनी कंपनी के लिए वेब प्रोजेक्ट का एक आर्केटाइप बना रहा हूं, विचार यह है कि एक नई परियोजना बनाने के लिए एक टेम्पलेट की तरह पहले से ही किया गया है, सुरक्षा, आईओसी, लॉगिंग इत्यादि ...

I मैं टेम्पलेट के सुरक्षा पक्ष पर काम कर रहा हूं ... और भिखारी पर मैं एक कस्टम सुरक्षा प्रदाता बनाना चाहता था ... लेकिन फिर मुझे एहसास हुआ कि माइक्रोसॉफ्ट ने पहले ही सदस्यता के साथ ऐसा किया है ... अगर किसी परियोजना को अलग-अलग की आवश्यकता होगी प्रदाता ... उन्हें केवल web.config को बदलने की आवश्यकता होगी और यह है ....

लेकिन फिर यह मेरी समस्या का कारण है ... यदि मैं अलग-अलग परतों को उपयोगकर्ताओं की जानकारी प्राप्त करने में सक्षम होना चाहता हूं .. जैसे सेवा परत (व्यापार सेवाएं ... वेब सेवाएं नहीं), मुझे इसमें शामिल करने की आवश्यकता होगी System.Web और System.Web.Aplication सेवा उस क्लास लाइब्रेरी में।

क्या यह एक बुरा अभ्यास है? मैं पहिया का पुन: आविष्कार नहीं करना चाहता हूं और माइक्रोसॉफ्ट सदस्यता मॉडल मेरे परिदृश्य के लिए पर्याप्त है।

धन्यवाद!

Answer 1

तथ्य यह है कि System.Web ASP.NET का हिस्सा है। System.Web में कई विधियां उदाहरण के लिए HttpContext.Current का उपयोग करती हैं - जो वर्तमान HTTP अनुरोध के बारे में संदर्भ है। एक गैर-ASP.NET अनुप्रयोग में System.Web का उपयोग अजीब तरीके से विफल होने का जोखिम चलाता है क्योंकि आपके पास उन विधियों के साथ कक्षाओं तक पहुंच है जो HttpContext का उपयोग कर सकते हैं। यह विचार अच्छा नहीं है; इसलिए, बदले में भी एक बुरा अभ्यास माना जाना चाहिए।

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

Answer 2

आपकी व्यावसायिक परत का उपयोग करने के लिए यह बुरा अभ्यास होगा, क्योंकि एक व्यावसायिक परत डेटा स्रोत स्वतंत्र होना चाहिए।

तो आप अपनी डेटा परतों में इसके बजाय कोई वेब अनुरोध करेंगे और केवल एकत्रित डेटा को अपनी व्यावसायिक परत या किसी भी अलग प्रमाणीकरण घटकों को आवश्यकतानुसार बेनकाब करें।

एक नियम के रूप में - आपकी व्यावसायिक परत में जो कुछ भी सख्ती से व्यवसाय नहीं है उसे परिभाषित इंटरफेस के साथ कक्षाओं में समेकित करने की आवश्यकता है।

Answer 3

System.Web किसी अन्य की तरह लाइब्रेरी है। हां, इसमें बहुत सारे कोड शामिल हैं, कॉम्पैक्ट फ्रेमवर्क में शामिल नहीं है और इसकी कुछ कार्यक्षमताओं को इसके बाहर दोहराया जा रहा है, उदाहरण के लिए WebUtility नेट 4.5 में नया है और HttpUtility करता है। हालांकि, यह सिर्फ एक कक्षा पुस्तकालय है।

Answer 4

मुझे लगता है कि यह बिल्कुल बुरा नहीं है। System.Web .NET ढांचे का एक हिस्सा है, इसलिए यह हर जगह उपलब्ध होगा जहां .NET उपलब्ध है। जब मैं एचटीएमएल और यूआरएल प्रसंस्करण के साथ काम करने की ज़रूरत है तो मैं गैर वेब अनुप्रयोगों में System.Web का उपयोग करता हूं।

Answer 5

यह समस्याग्रस्त हो सकता है क्योंकि System.Web .NET Framework क्लाइंट प्रोफ़ाइल का हिस्सा नहीं है। इसके संदर्भ में उपभोक्ताओं को पूर्ण ढांचा पैकेज स्थापित करने की आवश्यकता होगी। यदि आप सर्वर अनुप्रयोग बना रहे हैं तो शायद यह कोई मुद्दा नहीं है।

संदर्भ: Assemblies in the .NET Framework Client Profile

Answer 6

System.Web केवल आपके सामने के अंत में होना चाहिए। आपके वास्तुकला में हर जगह नहीं। सबसे अच्छा उदाहरण यह है कि Asp.Net 5 के साथ क्या चल रहा है, वे इसे हटा रहे हैं। अपने फ्रंट एंड लेयर पर अलग वेब घटक होने के कारण, आप अपने आर्किटेक्चर की सभी परतों को संशोधित करने से बचते हैं। आपको हमेशा मध्य (व्यापार तर्क, परिवर्तन तर्क, आदि) और बैकएंड (डेटाबेस, इकाई फ्रेमवर्क, वेब एपीआई कॉल) से सामने (वेब, वेब एपीआई, सिग्नलआर, आदि) को अलग करने की कोशिश करनी चाहिए।