Comparison of common reading and writing schemes for Web site profiles in XML format

xml| comparison

Web site configuration file, but not only web.config one, there are many other, the following to analyze a few common.

The revelation of web.config
The benefits of web.config are needless to say, and below are some of his limitations.

1. For Web applications, modifying the Web.config file will automatically restart the Web application.

If we have a configuration that is expected to change from time to time, or if we do not want to modify it, the WEB application will automatically restart. You should not put him in the web.config.

Example:
asp.net 2.0 new SITEMAP configuration file, obviously you have a site which file configuration information will be more frequent changes, and here's the modification, should not let the site back up.
Microsoft has not put this configuration into the web.config. Of course not. There are other considerations, which will be mentioned later.

See:
The AppDomain reboot may be based on the following factors:
1. Various properties (for example, the MemoryLimit property) are modified, and the settings in the configuration file section are modified.
2, Global.asax or Web.config file modification.
3, modify the Web application Bin directory.
4, virus scanning software touches some. config files
Http://support.microsoft.com/kb/324772/zh-cn
http://support.microsoft.com/default.aspx?scid=kb; en-us;q324772

2, Web.config file should not be too big
Otherwise, Microsoft does not have to set up, each directory can put a Web.config file.
Do not put all these configurations under a single file??

One consideration of the Sitemap configuration file as mentioned above is that the sitemap file can be very large,
In addition, the need for users to handle a SiteMap as a data source is strong, so there is a SiteMapDataSource Web server control. Tightly tied to SiteMap files. This special requirement leads to not putting this information into the web.config.

Read-write operations configured with custom configuration sections, configuration section groups, and configuration handler declarations.

This set of working mechanism, is the web.config internal reading and writing mechanism, Web.config configuration is based on this set, increased the monitoring file changes and other logical operation of the processing mechanism.

This set of mechanism configuration file format:
All configuration information resides in the configuration element in the configuration file.
The configuration information in this element is divided into two primary zones: The configuration section handler declares the zone and the configuration section Settings area.

What you need to do when you add or adjust a configuration:
1, adjust the new configuration section, configuration section group class, to ensure that the new, adjusted architecture.
All of these configuration section classes must derive from ConfigurationElement, ConfigurationElementCollection, ConfigurationSection, one of the classes. Each configuration section is a class, so one of your configuration requirements may eventually evolve into multiple configuration classes.
2, modify the configuration file:
This includes two parts:
2.1. Adjust the configuration section handler declaration to ensure that your new configuration structure is declared correctly.
2.2, adjust the specific configuration value
In the above steps, there may be some steps that need not be adjusted when the configuration is specifically tuned.

The limitations of this set of mechanisms:
1, each configuration node needs a configuration class corresponding, this node's parent class can only be ConfigurationElement, ConfigurationElementCollection, configurationsection one of them.
2, a business logic configuration needs, may require more than one configuration node compounding class corresponding.
3, Business logic classes and business logic settings classes, most of the cases must be separated, can not be integrated into the same class.
4, the configuration file must have the configuration data Provider declaration.
5, add or adjust a configuration structure is more complex, there are a large number of entity classes need to implement, but if this configuration has been implemented, modify the configured value, there is no complexity. You just need to change one place.

So this set of configuration mechanism is not suitable for a few scenarios as follows:
1, if the configuration structure is expected to change constantly, it is not appropriate. There are so many things that change every time.
2, if it is a small application, in order to achieve this configuration, an additional number of classes, not cost-effective.

But if it is a large project, and the design of stereotypes, will not change in the case, it is more appropriate.
That is, the business logic, and the business logic configuration can be expected in the future, will not change greatly, it is acceptable.

Three, Community Server in the communityserver.config configuration file read mode.

That is, when you read the configuration file as an XML file, we can bundle the business class and configuration tightly together.

Let's look at how the specific Community Server is done.
The Communityserver.config configuration file corresponds to a configuration class csconfiguration.
Csconfiguration loads the Communityserver.config as an XML file into the XmlDocument object, and the instance of the XmlDocument object is cached in memory.

This part of his implementation code is as follows:

public static csconfiguration GetConfig ()
... {
csconfiguration config = cscache.get (cachekey) as csconfiguration;
if (config = = null)
... {
string path = null;
HttpContext context = HttpContext.Current;
If (context!= null)
Path = context. Server.MapPath ("~/communityserver.config");
Else
Path = Path.Combine (AppDomain.CurrentDomain.BaseDirectory, "communityserver.config");
XmlDocument doc = new XmlDocument ();
Doc. Load (path);
Config = new csconfiguration (DOC);
Cscache.max (cachekey,config,new cachedependency (path));
Cscache.resetfactor (config. Cachefactor);
}
return config;
}
In Community Server, there is a processing mechanism for scheduled tasks, which are timed to do some work in the process of WEB applications.

These timed threads, where they are called Job.
The business logic and job configuration information for each job is encapsulated in the job class.
This part of his implementation code is as follows.

public class Job:idisposable
... {
Public Job (Type ijob, XmlNode node)
... {
_node = node;
_jobtype = Ijob;

XmlAttribute att = node. attributes["Enabled"];
if (att!= null)
this._enabled = bool. Parse (Att. Value);

att = node. attributes["Enableshutdown"];
if (att!= null)
This._enableshutdown = bool. Parse (Att. Value);
.......
}
}

The constructor for each job, which has a XmlNode node object in the incoming argument, is the various settings information for the job in the configuration file.

In the constructor, we get these setting parameters and then start a different Job by these parameters.

The benefits of doing so:
1. I have a new job type that needs to be developed, and the job type that needs to be newly developed has several new information that needs to be configured.

At this point, I just need to manually add these configurations to the configuration file,
Then, in the job class, implement the business logic of the job and read the configuration information. is done.

We typically change only two files to achieve this business logic requirement.
If we look at the read and write operations that are configured using the Custom configuration section, the configuration section group, and the configuration handler declaration method in this article, how much code needs to be changed.

Summarize

Select the profile you want on demand and the working mechanism for configuring read and write.