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

Khi phát triển Ứng dụng .NET Windows Forms, chúng tôi có lựa chọn giữa các App.configthẻ đó để 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>

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

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

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

Nếu bạn có thể, tôi muốn và khuyên bạn nên sử dụng các phần cấu hình của riêng bạn - với .NET 2.0, điều đó 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à kiểm tra chúng an toàn
• b) Bạn có thể tách biệt rõ ràng các cài đặt CỦA BẠN khỏi mọi người 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 viết thực sự hay về bạn để làm sáng tỏ hệ thống cấu hình .NET 2.0 trên CodeProject:

1. Làm sáng tỏ những bí ẩn của cấu hình .NET 2.0

2. Giải mã những bí ẩn của cấu hình .NET 2.0

3. Bẻ khóa những bí ẩn của cấu hình .NET 2.0

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

Cài đặt ứng dụng có thể được kiểm soát từ nhà thiết kế (thường có tệp Cài đặt cài đặt theo mặc định) để dễ sửa đổi hơn và bạn có thể truy cập chúng theo chương trình thông qua lớp Cài đặt nơi chúng xuất hiện như một thuộc tính được gõ mạnh. Bạn cũng có thể có cài đặt cấp độ ứng dụng và người dùng, cũng như cài đặt mặc định để khôi phục.

Điều này có sẵn từ .NET 2.0 trở đi và không dùng cách khác để làm điều đó (theo như tôi có thể nói).

Thông tin chi tiết được đưa ra tại: msdn.microsoft.com/en-us/l Library / k4s6c3a0.aspx

Tôi đã sử dụng một mẫu mà tôi đã tìm thấy trước đây khi bạn sử dụng các thẻ xml cơ bản nhưng bọc các cài đặt trong một lớp cấu hình tĩnh. Vì vậy - một ứng dụng DIY. Cài đặt.

Mẫu cấu hình tĩnh DotNetPearls

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

• sử dụng các bộ giá trị cấu hình khác nhau cho các môi trường khác nhau (dev, test, prod)
• cung cấp các giá trị mặc định hợp lý cho từng cài đặt
• kiểm soát cách các giá trị được xác định và khởi tạo

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 chính và được gõ mạnh. Kiểu mẫu này hoạt động tốt cho cấu hình không bị thay đổi bởi ứng dụng, mặc dù bạn có thể cũng có thể hỗ trợ cho các thay đổi.

Cấu hình:

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

Lớp cấu hình:

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
    }

Để hiểu những ưu và nhược điểm của cài đặt trong app.config, tôi khuyên bạn nên xem xét 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 mã nguồn để xử lý, mô tả chi tiết kỹ thuật bên dưới.

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

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

Ưu

• Chúng cho phép lưu trữ dữ liệu đã nhập, bao gồm các loại đối tượng (thông qua thuộc serializeAstính)

• Họ có phạm vi người dùng và ứng dụng, cho phép lưu trữ các giá trị mặc định

• Chúng được hỗ trợ trong phần cấu hình của Visual Studio

• Các chuỗi dài và / hoặc dữ liệu có các ký tự đặc biệt được hỗ trợ rất tốt (ví dụ: các chuỗi JSON được nhúng có chứa 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 trong hồ sơ người dùng (với đường dẫn khó hiểu), có thể khó dọn dẹp

• Cài đặt phạm vi ứng dụng là chỉ đọc trong 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)

• Mã phương thức đọc / ghi được xây dựng bởi nhà thiết kế cài đặt của Visual Studio, không được cung cấp trực tiếp bởi các công cụ của bên thứ 3 (xem liên kết ở trên để biết giải pháp khắc phục)

Cài đặt ứng dụng trong .NET
Update: Cài đặt ứng dụng trong .NET Core
(nhấp vào bên trên để xem mã nguồn và chi tiết kỹ thuật)

Ưu

• 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

• Chúng có thể được chỉnh sửa dễ dàng bởi Quản trị viên trong
  Trình quản lý dịch vụ thông tin Internet (IIS)
  ^{(Chế độ xem tính năng -> Cài đặt ứng dụng, lưu ý rằng tên của biểu tượng bị sai lệch vì nó chỉ có thể xử lý Cài đặt ứng dụng chứ không phải Cài đặt ứng dụng)}

Nhược điểm

• Chỉ hỗ trợ dữ liệu chuỗi; độ dài chuỗi và ký tự đặc biệt bị giới hạn

• Họ không có phạm vi người dùng

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

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

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 các 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 lớp tại đây:

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