Ưu điểm và nhược điểm của AppSettings so với applicationSettings (.NET app.config/Web.config)

Question

Khi phát triển .NET Windows Forms Application, chúng tôi có sự lựa chọn giữa các thẻ App.config để lưu trữ các giá trị cấu hình của chúng tôi. Cái nào tốt hơn?

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

Answer 1

Các cơ bản <appSettings> là dễ dàng hơn để đối phó với - chỉ tát vào một mục <add key="...." value="..." /> và bạn đã hoàn tất.

Nhược điểm là: không có kiểm tra loại, ví dụ: bạn không thể giả định một cách an toàn số của bạn mà bạn muốn cấu hình có thực sự là một số - ai đó có thể đặt một chuỗi vào thiết lập đó ..... bạn chỉ cần truy cập nó như ConfigurationManager["(key)"] và sau đó nó tùy thuộc vào bạn để biết bạn đang xử lý .

Ngoài ra, theo thời gian, <appSettings> có thể trở nên phức tạp và lộn xộn, nếu nhiều phần của ứng dụng của bạn bắt đầu đưa nội dung vào đó (nhớ tệp windows.ini cũ? :-)).

Nếu có thể, tôi sẽ thích và khuyên bạn sử dụng các phần cấu hình riêng của bạn - với .NET 2.0, nó thực sự trở nên khá dễ dàng, Bằng cách đó, bạn có thể:

• a) Xác định cài đặt cấu hình của bạn trong mã và có chúng an toàn loại và kiểm tra
• b) Bạn có thể tách riêng các thiết lập CỦA BẠN từ mọi người các thiết bị khác. Và bạn cũng có thể sử dụng lại mã cấu hình của mình!

Có một loạt các bài báo thực sự tốt về bạn làm sáng tỏ hệ thống cấu hình NET 2.0 trên CodeProject:

1. Unraveling the mysteries of .NET 2.0 configuration

2. Decoding the mysteries of .NET 2.0 configuration

3. Cracking the mysteries of .NET 2.0 configuration

Rất khuyến khích! Jon Rista đã làm một công việc tuyệt vời giải thích hệ thống cấu hình trong .NET 2.0.

Answer 2

Cài đặt ứng dụng có thể được điều khiển từ một nhà thiết kế (thường có một tập tin Settings.settings theo mặc định) nên nó dễ dàng hơn để chỉnh sửa và bạn có thể truy cập chúng lập trình thông qua các lớp Cài đặt nơi họ xuất hiện như một tài sản mạnh mẽ gõ . Bạn cũng có thể có cài đặt cấp ứng dụng và cấp người dùng cũng như cài đặt mặc định để quay lại.

Tính năng này có sẵn từ .NET 2.0 trở đi và không dùng cách khác để thực hiện (theo như tôi có thể biết).

Xem chi tiết được đưa ra tại địa chỉ: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Answer 3

Tôi thích làm việc với phiên bản đơn giản hơn để lưu trữ và truy cập các giá trị đơn lẻ.

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

Tôi đã viết một lớp tiện ích để truy cập các giá trị theo cách an toàn cho phép giá trị mặc định. Nếu mặc định không được cung cấp, thì các thông báo ngoại lệ hữu ích sẽ được cung cấp.

Bạn có thể xem/tải về lớp đây:

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

Answer 4

Tôi đã sử dụng một mô hình tôi thấy một khi trở lại nơi bạn sử dụng thẻ xml cơ bản nhưng quấn các thiết lập trong một lớp cấu hình tĩnh. Vì vậy - một App.Settings DIY.

DotNetPearls Static Config Pattern

Nếu bạn làm theo cách này bạn có thể:

• sử dụng bộ khác nhau của các giá trị cấu hình cho các môi trường khác nhau (dev, kiểm tra, prod)
• cung cấp cho giá trị mặc định hợp lý cho mỗi thiết lập
• kiểm soát cách xác định giá trị và được tạo ra ngay lập tức

Thật tẻ nhạt khi thiết lập nhưng hoạt động tốt, ẩn các tham chiếu đến các tên khóa và được đánh máy mạnh. Kiểu mẫu này hoạt động tốt cho cấu hình không được ứng dụng thay đổi, mặc dù bạn có thể cũng hỗ trợ thay đổi.

Config:

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

Config lớp:

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 
    } 

Answer 5

Để hiểu được ưu và khuyết điểm các thiết lập trong app.config, tôi đề nghị bạn nên nhìn vào các chi tiết kỹ thuật của cả hai . Tôi đã bao gồm các liên kết nơi bạn có thể tìm thấy mã nguồn để xử lý, mô tả chi tiết kỹ thuật bên dưới.

Hãy để tôi một thời gian ngắn tóm tắt những gì tôi ghi nhận khi tôi đã làm việc với họ (lưu ý: cùng được áp dụng cho các tập tin web.config của một trang web/ứng dụng web):

---

applicationSettings
(nhấp vào bên trên để xem mã nguồn và chi tiết kỹ thuật)

Ưu tiên

• Chúng cho phép để lưu trữ dữ liệu đánh máy, bao gồm các loại đối tượng (thông qua serializeAs tài sản)

• Họ có một người sử dụng và phạm vi áp dụng, cho phép các giá trị mặc định cửa hàng

• Họ được hỗ trợ trong Visual Phần cấu hình của Studio

• Chuỗi dài và/hoặc dữ liệu có ký tự đặc biệt được hỗ trợ rất tốt (ví dụ: chuỗi JSON được nhúng có chứa gấp đôi dấu ngoặc kép)

Nhược điểm

• Cài đặt người dùng được lưu trữ ở một nơi khác nhau trong hồ sơ người dùng (với một con đường khó hiểu), có thể khó khăn để làm sạch

• Cài đặt phạm vi ứng dụng là chỉ đọc trong suốt thời gian chạy của ứng dụng (chỉ có thể thay đổi cài đặt phạm vi người dùng trong thời gian chạy)

• Đọc/Viết phương pháp đang được xây dựng bởi nhà thiết kế thiết lập Visual Studio, chứ không phải trực tiếp bởi công cụ của bên thứ 3 cung cấp (xem liên kết ở trên một giải pháp workaround)

---

AppSettings
(bấm trên để xem mã nguồn và chi tiết kỹ thuật)

Ưu tiên

• Là "trọng lượng nhẹ", tức làdễ dàng để xử lý

• Đọc và viết truy cập trong thời gian chạy của ứng dụng

• Họ có thể được chỉnh sửa một cách dễ dàng bởi Quản trị viên trong
  Internet Information Services (IIS) Manager
  ^{(Tính năng View -> Cài đặt ứng dụng , lưu ý rằng tên của biểu tượng là sai lầm vì nó chỉ có thể xử lý AppSettings và không ApplicationSettings)}

Nhược điểm

• Hỗ trợ chỉ chuỗi dữ liệu; chiều dài chuỗi và ký tự đặc biệt được giới hạn

• Họ không có một phạm vi sử dụng

• Họ không ủng hộ các giá trị mặc định

• đang không được hỗ trợ trực tiếp trong phần cấu hình của Visual Studio

---