Recently I have studied the source code of Microsoft Enterprise Library configuration, and I have a general understanding of its architecture. I have learned a lot about it. Although the code is simple, its architecture is flexible, scalability and configurability. It is worth learning and signing.
In daily work, a system application is not considered at the framework height. It may be because of laziness or too many problems to consider, so the Code Compiled is very rigid. A slight change in system requirements will often lead to modifications to the entire system code. Well, this may be the cost of growth.
To put it bluntly, configuration has its own characteristics: because it is in the most basic infrastructure, it requires flexible architecture and can be stored from various types (XML, SQL Server ...) Read and Write configuration data. Configuration is defined rather than configuration. It defines how to read and write data from the storage and convert it to the configuration class that the user (system) wants to see. This is also called interface-oriented programming.
The first solution is to configure the provider interface. configuration provides the iconfigurationprovider interface. The Protocol is as follows: configurationname attribute and initialize (configurationview) method;
That is to say, any configuration provider must have a configuration name and can be initialized (the configurationview is the metadata information view)
Secondly, istorageproviderreader inherits the iconfigurationprovider interface and provides the currentsectionname (currently the configuration node name to be read) Attribute and read method.
The next step is to implement the configurationprovider abstract class of the iconfigurationprovider interface, which specifies the method to be implemented by the actual configuration provider, that is
Initialize (configurationview) abstract method. In fact, this class has nothing to do.
The following is the storage provider: storageprovider, which inherits the istorageproviderreader interface and configurationprovider class. In this way, a storage provider integrates the two protocols and has the following implementation methods:
Initialize (), read ().
After reading data from the memory, if you want to, you can send the data directly to the system. For example, the notorious dataset, but configuration provides us with the converter interface itransformer, which converts the data provided by storageprovider into the information body (domain class or dataset) that the System user wants to see ), configuration only treats this process as a black box and provides middleware functions, such as caching and monitoring of its actions. The itransformer method should be parsing and packaging:
Deserialize (), serialize (), of course, it also needs to be initialized, so it also inherits the iconfigurationprovider interface,
In addition, configuration encapsulates the converter interface as an abstract class: transformerprovider. This class not only inherits the itransformer, but also inherits the configurationprovider. The actual method to implement this converter is:
Initialize (), deserialize (), serialize ()
After configuration defines the storage provider and converter, the next thing is to provide the actual storage provider and converter to the configuration through the factory mode. In this way, configuration writes a general abstract factory configurationfactory, which is used to obtain the context of configuration and createinstance (string configurationname), a configuration class of the configuration name. In this method, it works on Createobject (). (Note: Both the storage provider and The Transcoder are the configurator, which is somewhat far-fetched.) Next, providerfactory inherits configurationfactory and has no major functions, it overrides Createobject () to initialize the storage provider and The Transcoder, which is why the iconfigurationprovider has the initialize method.
Finally, configuration writes storageproviderfactory and transformerfactory for the storage provider and The Transcoder respectively. Of course, both of them inherit providerfactory. In these two classes, they do a very important job. The getconfigurationtype () method of configurationfactory is implemented. Why? Well, I don't know. I don't know this method. The createinstance of configurationfactory is a tough option.
The class relationship between the provider and the converter is as follows: