Thông báo


Chia sẻ
Tùy chọn
Xem bài viết cuối
Offline admin  
#1 Đã gửi : 10/06/2016 lúc 03:02:34(UTC)

Danh hiệu: Administration

Chức danh:

Nhóm: Administrators
Gia nhập: 23-07-2013(UTC)
Bài viết: 6,108
Viet Nam
Đến từ: Vietnam

Cảm ơn: 10 lần
Được cảm ơn: 2 lần trong 2 bài viết

Current Implementation

The common classes for configuration support are based around config files saved in a particular XML format. There is a configuration manager that has static methods for loading and saving configuration files and accessing the loaded data. Each section of a configuration file is represented by a config object which contains a number of named values. The config object may also be used independently of a config file as a means of serialising values (for example, the parameters for a job are managed using config objects). The problems with this approach are:

  • The configuration manager effectively creates global members and methods and all consumers of data from it are coupled to it.
    • No class requiring configuration data can be used in a context where there is not a config file loaded into the manager.

    • This limits the testability of consumers of configuration data because we cannot supply a mock config provider to the code under test.

  • As the configuration manager uses static members the data will be unavailable in secondary AppDomains.

  • It is not possible to use alternative providers of configuration data (a database, memory store, alterative file formats or whatever).

  • Config is annoying to use (cannot have a single line call to get a value as we need to declare a variable and pass it in as an out param) and lacks flexibility in some respects (for example, we cannot store multiple values with the same key without a workaround).

  • The logic for loading a config from a file is within Config and that class can also be used to manipulate config files, including loading and saving individual configs.
    • This means that the config object is now tied to the specific format of config information in the files we currently use.

    • It also means that there is no single consistent way of working with config files (the server uses the config manager and the clients typically use Config to access files).

Configuration Approach

A new approach to handling config data would be built around decoupling the physical store of configuration data from the consumer of that data. This would support a common method for interacting with config data and also allow different providers to be used if required. The following diagram illustrates the separation required.

configuration approach

The consumer is provided with an interface to a configuration provider. The implementation behind that is responsible for the physical storage of the data. The consumer interacts with the provider in an abstract way to obtain and/or create and edit config objects which contain the data.

There is scope for making the config object more developer friendly than the current Config and for extending the interface to support multiple configs and/or values with the same name.

Ai đang xem chủ đề này?
OceanSpiders 2.0
Chủ đề tương tự
Software Configuration Approach (Giải pháp lập trình)
Bởi admin 10-06-2016 lúc 03:14:04(UTC)
Di chuyển  
Bạn không thể tạo chủ đề mới trong diễn đàn này.
Bạn không thể trả lời chủ đề trong diễn đàn này.
Bạn không thể xóa bài của bạn trong diễn đàn này.
Bạn không thể sửa bài của bạn trong diễn đàn này.
Bạn không thể tạo bình chọn trong diễn đàn này.
Bạn không thể bỏ phiếu bình chọn trong diễn đàn này.

| Cung cấp bởi YAF.NET | YAF.NET © 2003-2020, Yet Another Forum.NET
Thời gian xử lý trang này hết 0.235 giây.