वेब ऐप में स्थिर और इंस्टेंस डेटा एक्सेस क्लास के बीच चयन करने के पेशेवर/विपक्ष क्या हैं?

Question

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

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

विशेष रूप से, मुद्दों के बारे में मैं चिंतित हूँ हैं:

1. & संगामिति
2. अनुमापकता
3. प्रदर्शन
4. किसी भी अन्य अज्ञात

धन्यवाद थ्रेडिंग!

Answer 1

स्टेटिक आधारित दृष्टिकोण वास्तव में आम तौर पर एक होते हैं, और केवल एक, मुख्य लाभ: वे कार्यान्वित करने में आसान होते हैं। ऊपर

Perf के रूप में एक ही मुद्दों - ताकि आप बेहतर प्रवाह

अनुमापकता मिलता है, आप किसी भी/के रूप में ज्यादा तुल्यकालन जरूरत नहीं है -

1. थ्रेडिंग और संगामिति:

   उदाहरण आधारित दृष्टिकोण के लिए जीतने के लिए।- इसके बाद के संस्करण

2. Testability के रूप में एक ही मुद्दों - यह बहुत परीक्षण करने के लिए आसान है, क्योंकि एक उदाहरण बाहर मजाक आसान है, और स्थैतिक कक्षाओं का परीक्षण परेशानी है

स्टेटिक दृष्टिकोण पर जीत सकते हैं:

1. मेमोरी - आपके पास केवल एक उदाहरण है, इसलिए कम पदचिह्न
2. संगति/साझाकरण - एक उदाहरण को अपने साथ संगत रखना आसान है।

सामान्यतः, मुझे लगता है कि उदाहरण-आधारित दृष्टिकोण बेहतर हैं। यदि आप एक ही सर्वर से आगे बढ़ने जा रहे हैं, तो यह अधिक महत्वपूर्ण हो जाता है, क्योंकि जैसे ही आप इसे एकाधिक मशीनों पर इंस्टेंस करना शुरू करते हैं, स्थिर दृष्टिकोण "ब्रेक" होगा ...

Answer 2

मेरी सामान्य भावना है: यदि आपको आवश्यकता नहीं है तो तत्काल क्यों करें?

मैं स्थिर वर्गों का उपयोग करता हूं जब कई उदाहरणों के लिए कोई उपयोग नहीं होता है और उदाहरण सदस्यों की आवश्यकता नहीं होती है। डीएएल के लिए, मुद्दा यह है कि केवल एक ही है। अगर इसमें कोई मूल्य नहीं है तो इसे तुरंत क्यों करें?

this link पर देखें, जो दर्शाता है कि स्थिर विधि कॉल उदाहरण क्लास विधि कॉल से तेज हैं।

This link दिखाता है कि एक स्थिर वर्ग का उपयोग करने का एक लाभ यह है कि संकलक यह सुनिश्चित करने के लिए जांच कर सकता है कि कोई इंस्टेंस सदस्य गलती से जोड़े नहीं गए हैं।

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

Answer 3

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

List<Entity> tableRows = SQL.Read(new SearchCriteria(), new Table()); 

सब कुछ एसक्यूएल स्थिर वर्ग से निकलता है, और यह मेरे कोड को बहुत आसान बनाता है।

Answer 4

मेरे लिए मुख्य कारण यह है कि मुझे उस डीएएल ऑब्जेक्ट की स्थिति को रखने की आवश्यकता नहीं है। जिस वस्तु का उपयोग वह करता है, वह उस विधि के दायरे को फैलाता नहीं है जिसे वे एम्बेड कर रहे हैं। इस तरह आप एक वस्तु के कई उदाहरण क्यों रखेंगे, अगर वे सब एक जैसे हैं?

ADO.NET के नवीनतम संस्करणों के साथ, आपके कॉल के दायरे में डेटाबेस के कनेक्शन को बनाने और नष्ट करने का सबसे अच्छा अभ्यास प्रतीत होता है, और ConnectionPool को पूरी कनेक्शन पुन: प्रयोज्यता समस्या का ख्याल रखना चाहिए।

फिर से .NET Framework के नवीनतम संस्करणों के साथ, लेनदेनस्कोप (जो आपके कनेक्शन को प्रबंधित करने का एक कारण होगा) व्यवसाय स्तर तक बढ़ता है, जो आपको उसी दायरे में डीएएल को एकाधिक कॉल में शामिल होने की अनुमति देता है।

तो मैं डीएएल के उदाहरण बनाने और नष्ट करने (या कैश) उदाहरणों के लिए एक आकर्षक केस नहीं देख सकता।