AppSettings बनाम ApplicationSettings (.NET app.config / Web.config) के पेशेवरों और विपक्ष

166

.NET विंडोज फॉर्म एप्लीकेशन को विकसित करते समय हमारे पास उन App.configकॉन्फ़िगरेशनों के बीच विकल्प होता है जो हमारे कॉन्फ़िगरेशन मूल्यों को संग्रहीत करते हैं। इनमे से कौन बेहतर है?

<configuration>

  <!-- Choice 1 -->
  <appSettings>
    <add key="RequestTimeoutInMilliseconds" value="10000"/>
  </appSettings>

  <!-- Choice 2 -->
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" >
        <section name="Project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Project1.Properties.Settings>
      <setting name="TABLEA" serializeAs="String">
        <value>TABLEA</value>
      </setting>
    </Project1.Properties.Settings>
  </applicationSettings>

</configuration>

.net web-config app-config

— जदर दयस
स्रोत

MS उदाहरण कोड में वे appSettings का उपयोग करते हैं msdn.microsoft.com/en-us/library/… यह मुझे भ्रामक लगता है :(

— हंट

इस लेख को मिला codeproject.com/KB/files/… यह प्रतीत होता है कि appSettings w / r के लिए हैं एक applicationSettings केवल पढ़ने के लिए हैं।

— हंट

एक अन्य लेख जो प्रासंगिक stackoverflow.com/questions/453161/… है

— हंट

ध्यान दें कि वही web.config पर लागू होता है, इसलिए मैंने इस प्रश्न में web.config टैग जोड़ा है।

— मैट

151

मूल <appSettings>से निपटने के लिए आसान है - बस एक <add key="...." value="..." />प्रविष्टि में थप्पड़ और आप कर रहे हैं।

नकारात्मक पक्ष यह है: कोई प्रकार की जाँच नहीं है, उदाहरण के लिए, आप सुरक्षित रूप से अपना नंबर नहीं मान सकते हैं जिसे आप वहां कॉन्फ़िगर करना चाहते हैं वास्तव में एक संख्या है - कोई व्यक्ति उस सेटिंग में एक स्ट्रिंग डाल सकता है ..... आप इसे बस के रूप में एक्सेस करते हैं ConfigurationManager["(key)"]और फिर यह ऊपर है आपको पता है कि आप किसके साथ काम कर रहे हैं।

इसके अलावा, समय के साथ, <appSettings>बल्कि जटिल और गड़बड़ हो सकता है, अगर आपके ऐप के बहुत सारे हिस्से वहाँ सामान डालना शुरू कर दें (पुरानी windows.ini फ़ाइल को याद रखें? :-))।

यदि आप कर सकते हैं, तो मैं अपने स्वयं के कॉन्फ़िगरेशन अनुभागों का उपयोग करना पसंद करूंगा और सुझाऊंगा - .NET 2.0 के साथ, यह वास्तव में काफी आसान है, इस तरह, आप कर सकते हैं:

a) अपनी कॉन्फ़िगरेशन सेटिंग्स को कोड में परिभाषित करें और उन्हें टाइप-सेफ और चेक करें
b) आप अपनी सेटिंग को साफ़ तौर पर हर किसी से अलग कर सकते हैं । और आप अपने config कोड का पुनः उपयोग कर सकते हैं!

CodeProject पर .NET 2.0 कॉन्फ़िगरेशन सिस्टम को ध्वस्त करने के लिए आप पर बहुत अच्छे लेखों की एक श्रृंखला है:

अत्यधिक सिफारिशित! जॉन रिस्ता ने .NET 2.0 में कॉन्फ़िगरेशन सिस्टम की व्याख्या करते हुए बहुत अच्छा काम किया।

— marc_s
स्रोत

2

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

— markmnl

20

एप्लिकेशन सेटिंग्स को एक डिजाइनर से नियंत्रित किया जा सकता है (आमतौर पर डिफ़ॉल्ट रूप से Settings.settings फ़ाइल होती है) इसलिए इसे संशोधित करना आसान है और आप उन्हें सेटिंग्स वर्ग के माध्यम से प्रोग्रामेटिक रूप से एक्सेस कर सकते हैं जहां वे एक दृढ़ता से टाइप की गई संपत्ति की तरह दिखाई देते हैं। आपके पास एप्लिकेशन और उपयोगकर्ता स्तर सेटिंग्स भी हो सकती हैं, साथ ही वापस रोल करने के लिए डिफ़ॉल्ट सेटिंग्स भी हो सकती हैं।

यह .NET 2.0 से उपलब्ध है और इसे करने के दूसरे तरीके (जहां तक मैं बता सकता हूं) को दर्शाया गया है।

अधिक विवरण यहाँ दिया गया है: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

— पीटर सी
स्रोत

14

मैं कुछ समय पहले पाया गया एक पैटर्न का उपयोग कर रहा हूँ जहाँ आप बेसिक xml टैग का उपयोग करते हैं, लेकिन सेटिंग्स को एक स्थिर विन्यास वर्ग में लपेटते हैं। तो - एक DIY ऐप।

DotNetPearls स्टेटिक कॉन्फ़िगरेशन पैटर्न

यदि आप इसे इस तरह से कर सकते हैं:

अलग-अलग वातावरणों के लिए अलग-अलग विन्यास के विभिन्न मूल्यों का उपयोग करें (देव, परीक्षण, ठेस)
प्रत्येक सेटिंग के लिए समझदार चूक के लिए प्रदान करते हैं
यह निर्धारित करें कि मान कैसे परिभाषित और त्वरित हैं

यह स्थापित करने के लिए थकाऊ है, लेकिन अच्छा प्रदर्शन करता है, प्रमुख नामों के संदर्भ छिपाता है, और दृढ़ता से टाइप किया जाता है। इस तरह का पैटर्न कॉन्फिगरेशन के लिए अच्छा काम करता है जो एप्लिकेशन द्वारा नहीं बदला जाता है, हालाँकि आप शायद बदलावों के समर्थन में भी काम कर सकते हैं।

कॉन्फ़िग:

<add key="machineName" value="Prod" />
<add key="anotherMachineName" value="Test" />
<add key="EnvTypeDefault" value="Dev" />

<add key="RootURLProd" value="http://domain.com/app/" />
<add key="RootURLTest" value="http://test.domain.com/app/" />
<add key="RootURLDev" value="http://localhost/app/" />

<add key="HumanReadableEnvTypeProd" value="" />
<add key="HumanReadableEnvTypeTest" value="Test Mode" />
<add key="HumanReadableEnvTypeDev" value="Development Mode" />

विन्यास वर्ग:

using System;
using System.Collections.Generic;
using System.Web;
using WebConfig = System.Web.Configuration.WebConfigurationManager;

    public static class Config
    {
        #region Properties

        public static string EnvironmentType { get; private set; }

        public static Uri RootURL { get; private set; }

        public static string HumanReadableEnvType { get; private set; }

        #endregion

        #region CTOR

        /// <summary>
        /// Initializes all settings when the app spins up
        /// </summary>
        static Config()
        {
            // Init all settings here to prevent repeated NameValueCollection lookups
            // Can increase performance on high volume apps

            EnvironmentType =
                WebConfig.AppSettings[System.Environment.MachineName] ??
                "Dev";

            RootURL =
                new Uri(WebConfig.AppSettings["RootURL" + EnvironmentType]);

            HumanReadableEnvType =
                WebConfig.AppSettings["HumanReadableEnvType" + Config.EnvironmentType] ??
                string.Empty;
        }

        #endregion
    }

— HAL9000
स्रोत

11

में सेटिंग्स के पेशेवरों और विपक्षों को समझने के लिए app.config, मेरा सुझाव है कि आप दोनों के तकनीकी विवरणों को देखें। मैंने ऐसे लिंक शामिल किए हैं जहां आप नीचे दिए गए अधिक तकनीकी विवरण का वर्णन करते हुए, हैंडलिंग के लिए स्रोत कोड पा सकते हैं।

जब मैंने उनके साथ काम किया तो मुझे संक्षेप में संक्षेप में बताएं ( नोट: वही web.configवेब साइट / ईमेल आईडी की फाइल पर लागू होता है ):

.NET में एप्लिकेशन सेटिंग
(स्रोत कोड और तकनीकी विवरण देखने के लिए ऊपर क्लिक करें)

पेशेवरों

वे ऑब्जेक्ट प्रकारों ( serializeAsसंपत्ति के माध्यम से ) सहित टाइप किए गए डेटा को स्टोर करने की अनुमति देते हैं
उनके पास एक उपयोगकर्ता और एप्लिकेशन गुंजाइश है, जो डिफ़ॉल्ट मानों को संग्रहीत करने की अनुमति देता है
वे विजुअल स्टूडियो के कॉन्फ़िगरेशन अनुभाग में समर्थित हैं
विशेष पात्रों के साथ लंबे तार और / या डेटा बहुत अच्छी तरह से समर्थित हैं (उदाहरण के लिए, डबल JSON वाले एम्बेडेड JSON तार)

विपक्ष

उपयोगकर्ता सेटिंग्स उपयोगकर्ता प्रोफ़ाइल में एक अलग स्थान पर संग्रहीत की जाती हैं (एक गुप्त पथ के साथ), सफाई करना मुश्किल हो सकता है
एप्लिकेशन स्कोप सेटिंग्स केवल एप्लिकेशन के रनटाइम के दौरान ही पढ़ी जाती हैं (रनटाइम के दौरान केवल उपयोगकर्ता स्कोप सेटिंग्स को बदला जा सकता है)
विजुअल स्टूडियो के सेटिंग डिजाइनर द्वारा निर्मित / लिखी गई विधियाँ कोड पढ़ें, सीधे 3 पार्टी टूल द्वारा प्रदान नहीं की गई हैं (वर्कअराउंड समाधान के लिए ऊपर लिंक देखें)

.NET
अद्यतन में AppSettings : .NET Core में AppSettings
(स्रोत कोड और तकनीकी विवरण देखने के लिए ऊपर क्लिक करें)

पेशेवरों

"हल्के वजन", संभाल करने के लिए आसान कर रहे हैं
एप्लिकेशन के रनटाइम के दौरान एक्सेस पढ़ें और लिखें
उन्हें
इंटरनेट सूचना सेवा (IIS) प्रबंधक में प्रशासकों द्वारा आसानी से संपादित किया जा सकता है
^{(सुविधाएँ देखें -> अनुप्रयोग सेटिंग्स, ध्यान दें कि आइकन का नाम भ्रामक है क्योंकि यह केवल AppSettings को संभाल सकता है और ApplicationSettings को नहीं)}

विपक्ष

केवल स्ट्रिंग डेटा का समर्थन करें; स्ट्रिंग की लंबाई और विशेष वर्ण सीमित हैं
उनके पास उपयोगकर्ता गुंजाइश नहीं है
वे डिफ़ॉल्ट मानों का समर्थन नहीं करते हैं
विजुअल स्टूडियो के कॉन्फ़िगरेशन अनुभाग में सीधे समर्थित नहीं हैं

— मैट
स्रोत

9

मुझे एकल मूल्यों को संग्रहीत करने और उन तक पहुंचने के लिए सरल संस्करण के साथ काम करना पसंद है।

<appSettings>
    <add key="MyConfigKey" value="true"/>
</appSettings>

मैंने एक उपयोगी वर्ग को मानों को एक ऐसे प्रकार से एक्सेस करने के लिए लिखा है जो डिफ़ॉल्ट मानों के लिए अनुमति देता है। यदि चूक प्रदान नहीं की जाती हैं, तो सहायक अपवाद संदेश दिए जाते हैं।

आप यहाँ कक्षा देख / डाउनलोड कर सकते हैं:

http://www.drewnoakes.com/code/util/app-settings-util/

— आकर्षित नोक
स्रोत

3

+1, यह विशेष रूप से सरल है यदि आपके पास कई विधानसभाएं हैं (सेटिंग्स में आमतौर पर प्रति विधानसभा एक अनुभाग होता है)। मेरा एक समान सहायक वर्ग है। BTW आपकी कक्षा वर्तमान में संस्कृति-संवेदी स्ट्रिंग्स का उपयोग करने के लिए कॉन्फ़िगर फ़ाइल की अपेक्षा करती है जो अच्छी बात नहीं है - जैसे "Double.TryParse (s, NumberStyles.Any, CultureInfo.InvariantCulture, आउट परिणाम) होना चाहिए" बजाय "Double.TryParse ( s, आउट परिणाम) "। इसके अलावा नाइटपिक के लिए, MS कोडिंग दिशानिर्देश GetInt32, GetInt16, GetBoolean के बजाय GetInt, GetShort, GetBool की सलाह देते हैं।

— जो

यह ठीक है, लेकिन AppSettings के समर्थक और विपक्ष के बारे में सवाल का जवाब नहीं देता है।

— मैट

@ मैट, प्रो है कि यह आसान है। कोन यह है कि यह सरल है। यदि आपको केवल शाब्दिक मूल्यों (बूल, इनट्स, स्ट्रिंग, आदि) के एक जोड़े की आवश्यकता है, तो यह दृष्टिकोण हिरन के लिए सबसे अधिक धमाके देता है। यदि आपको संरचित डेटा, नेमस्पेस पृथक्करण, XSD समर्थित सत्यापन / पूर्णता आदि की आवश्यकता है, तो एक कस्टम सेक्शन बेहतर हो सकता है। एक अन्य विकल्प App.configफ़ाइल को पूरी तरह से अनदेखा करना और अपनी स्वयं की कॉन्फ़िगरेशन फ़ाइल का उपयोग करना है। बहुत सारे पुस्तकालय ऐसा करते हैं। मन में आता है।

— ड्रू नॉक

@DrewNoakes - मैं आपसे सहमत हूँ। स्पष्टीकरण के लिए धन्यवाद।

— मैट