Pro dan kontra dari AppSettings vs applicationSettings (.NET app.config / Web.config)


166

Saat mengembangkan Aplikasi .NET Windows Forms kami memiliki pilihan di antara App.configtag tersebut untuk menyimpan nilai konfigurasi kami. Mana yang lebih baik?

<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>

Dalam contoh kode MS mereka menggunakan appSettings msdn.microsoft.com/en-us/library/... ini saya anggap membingungkan :(
Hunt

Ditemukan artikel ini codeproject.com/KB/files/... tampaknya menyiratkan bahwa appSettings adalah untuk w / r dan applicationSettings hanya untuk dibaca.
Berburu

Artikel lain yang relevan stackoverflow.com/questions/453161/…
Hunt

Perhatikan bahwa hal yang sama berlaku untuk web.config, jadi saya menambahkan tag web.config ke pertanyaan ini.
Matt

Jawaban:


151

Dasarnya <appSettings>lebih mudah ditangani - cukup dengan menampar <add key="...." value="..." />entri dan Anda selesai.

Kelemahannya adalah: tidak ada pengecekan tipe, mis. Anda tidak dapat dengan aman menganggap nomor yang ingin Anda konfigurasikan benar-benar ada angka - seseorang dapat memasukkan string ke dalam pengaturan itu ..... Anda cukup mengaksesnya ConfigurationManager["(key)"]lalu terserah. Anda tahu apa yang Anda hadapi.

Selain itu, seiring berjalannya waktu, proses <appSettings>dapat menjadi agak berbelit-belit dan berantakan, jika banyak bagian aplikasi Anda mulai meletakkan barang-barang di sana (ingat file windows.ini yang lama? :-)).

Jika Anda bisa, saya lebih suka dan merekomendasikan menggunakan bagian konfigurasi Anda sendiri - dengan .NET 2.0, itu benar-benar menjadi sangat mudah, Dengan begitu, Anda dapat:

  • a) Tentukan pengaturan konfigurasi Anda dalam kode dan minta mereka ketik aman dan diperiksa
  • b) Anda dapat memisahkan pengaturan ANDA dari orang lain secara bersih. Dan Anda juga dapat menggunakan kembali kode konfigurasi Anda!

Ada serangkaian artikel yang sangat bagus untuk Anda demistifikasi sistem konfigurasi .NET 2.0 pada CodeProject:

  1. Mengungkap misteri konfigurasi .NET 2.0

  2. Menguraikan misteri konfigurasi .NET 2.0

  3. Memecahkan misteri konfigurasi .NET 2.0

Sangat dianjurkan! Jon Rista melakukan pekerjaan yang hebat menjelaskan sistem konfigurasi di .NET 2.0.


2
Saya menemukan applicationSettings lebih mudah untuk menambahkan edit dan menghapus pengaturan plus Anda tidak harus menulis satu baris kode, ditambah mereka mengetik aman, ditambah Anda dapat lingkup mereka ke pengguna atau aplikasi, karena Anda bisa menggunakan tab Pengaturan di proyek Anda properti di VS.
markmnl

20

Pengaturan aplikasi dapat dikontrol dari desainer (biasanya ada file Settings.settings secara default) sehingga lebih mudah untuk dimodifikasi dan Anda dapat mengaksesnya secara terprogram melalui kelas Pengaturan di mana mereka muncul seperti properti yang sangat diketik. Anda juga dapat memiliki pengaturan tingkat aplikasi dan pengguna, serta pengaturan default untuk memutar kembali.

Ini tersedia dari .NET 2.0 dan seterusnya dan mencela cara lain untuk melakukannya (sejauh yang saya tahu).

Detail lebih lanjut diberikan di: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx


14

Saya telah menggunakan pola yang saya temukan beberapa waktu lalu di mana Anda menggunakan tag xml dasar tetapi bungkus pengaturan dalam kelas konfigurasi statis. Jadi - Aplikasi DIY. Pengaturan.

Pola Konfigurasi Statis DotNetPearls

Jika Anda melakukannya dengan cara ini, Anda dapat:

  • menggunakan set nilai konfigurasi yang berbeda untuk lingkungan yang berbeda (dev, test, prod)
  • menyediakan default yang masuk akal untuk setiap pengaturan
  • mengontrol bagaimana nilai didefinisikan dan dipakai

Sangat membosankan untuk mengatur tetapi berkinerja baik, menyembunyikan referensi untuk nama-nama kunci, dan sangat diketik. Pola semacam ini berfungsi dengan baik untuk konfigurasi yang tidak diubah oleh aplikasi, meskipun Anda mungkin bisa bekerja untuk mendukung perubahan juga.

Konfigurasi:

<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" />

Kelas konfigurasi:

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
    }

11

Untuk memahami pro dan kontra pengaturan di app.config, saya sarankan Anda melihat detail teknis keduanya. Saya telah menyertakan tautan tempat Anda dapat menemukan kode sumber untuk ditangani, menjelaskan lebih banyak detail teknis di bawah ini.

Biarkan saya meringkas secara singkat apa yang saya kenali ketika saya bekerja dengannya ( catatan: hal yang sama berlaku untuk web.configfile situs web / aplikasi web):


applicationSettings dalam .NET
(klik di atas untuk melihat kode sumber dan detail teknis)


Pro

  • Mereka memungkinkan untuk menyimpan data yang diketik, termasuk jenis objek (melalui serializeAsproperti)

  • Mereka memiliki ruang lingkup pengguna dan aplikasi, yang memungkinkan untuk menyimpan nilai default

  • Mereka didukung di bagian konfigurasi Visual Studio

  • String panjang dan / atau data dengan karakter khusus sangat didukung (misalnya, string JSON tertanam yang berisi tanda kutip ganda)


Cons

  • Pengaturan pengguna disimpan di tempat yang berbeda di profil pengguna (dengan jalur samar), bisa sulit untuk dibersihkan

  • Pengaturan cakupan aplikasi hanya baca selama runtime aplikasi (hanya pengaturan lingkup pengguna yang dapat diubah selama runtime)

  • Kode metode Baca / Tulis yang dibuat oleh desainer pengaturan Visual Studio, tidak secara langsung disediakan oleh alat pihak ke-3 (lihat tautan di atas untuk solusi penyelesaian masalah)


AppSettings dalam
Pembaruan .NET : AppSettings dalam .NET Core
(klik di atas untuk melihat kode sumber dan detail teknis)


Pro

  • Apakah "ringan", yaitu mudah ditangani

  • Akses baca dan tulis selama runtime aplikasi

  • Mereka dapat diedit dengan mudah oleh Administrator di
    Manajer Layanan Informasi Internet (IIS)
    (Tampilan Fitur -> Pengaturan Aplikasi, perhatikan bahwa nama ikon itu menyesatkan karena hanya dapat menangani AppSettings dan bukan ApplicationSettings)


Cons

  • Hanya mendukung data string; panjang string dan karakter khusus terbatas

  • Mereka tidak memiliki ruang lingkup pengguna

  • Mereka tidak mendukung nilai default

  • Tidak didukung secara langsung di bagian konfigurasi Visual Studio



9

Saya suka bekerja dengan versi yang lebih sederhana untuk menyimpan dan mengakses nilai tunggal.

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

Saya menulis kelas utilitas untuk mengakses nilai dengan cara yang aman yang memungkinkan untuk nilai default. Jika default tidak disediakan, maka pesan pengecualian yang bermanfaat diberikan.

Anda dapat melihat / mengunduh kelas di sini:

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


3
+1, lebih mudah terutama jika Anda memiliki banyak majelis (pengaturan biasanya memiliki bagian per perakitan). Saya memiliki kelas pembantu serupa. BTW kelas Anda saat ini mengharapkan file konfigurasi untuk menggunakan string yang peka terhadap budaya yang bukan hal yang baik - misalnya harus "Double.TryParse (s, NumberStyles. Setiap, CultureInfo.InvariantCulture, out result)" daripada "Double.TryParse ( s, hasil keluar) ". Juga untuk nitpick, pedoman pengkodean MS merekomendasikan GetInt32, GetInt16, GetBoolean daripada GetInt, GetShort, GetBool.
Joe

Itu bagus, tetapi tidak menjawab pertanyaan tentang pro dan kontra dari AppSettings.
Matt

@ Matt, pro adalah lebih sederhana. Yang menipu adalah bahwa itu lebih sederhana. Jika Anda hanya membutuhkan beberapa nilai literal (bools, ints, string, dll) maka pendekatan ini memberikan hasil maksimal. Jika Anda memerlukan data terstruktur, pemisahan namespace, validasi / penyelesaian XSD yang didukung, dll, maka bagian khusus mungkin lebih cocok. Pilihan lain adalah mengabaikan App.configfile sama sekali dan menggunakan file konfigurasi Anda sendiri. Banyak perpustakaan yang melakukannya. NLog datang ke pikiran.
Drew Noakes

@DrewNoakes - Saya setuju dengan Anda. Terimakasih atas klarifikasinya.
Matt
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.