Improve performance with static read-only fields and static constructors

Main content Sentence Summary:

The relatively fixed data is compiled at compile time only by querying the database once to the exposed static read-only generic collection type field, thereby eliminating subsequent possible database queries to improve performance.

Background: Our applications often require collection data that is similar to the national list of provinces, which are basically fixed or are changed for a long time. For such data, one of the common practices in development is to have the data in a database table and then populate it where needed. I think this is a dirty thing, because it doesn't make sense for us to look at these fixed data many times, or even further we cache the data to avoid some queries to improve performance, which is to take advantage of the principle of the single piece mode (I'm not familiar with the pattern, the feeling cache seems to be the same as the single piece pattern) Do not know if this understanding is appropriate, I hope the replies to testify against me ah. However, both caching and monolithic mode require additional logic (caching scenarios require logic such as determining whether cached data exists, adding expiration policies, and a single piece pattern must have a similar logic), which is simple but also affects performance.

Solution:

Storing data in a static read-only field, connecting the database within a static constructor to complete a data query, assigning the data to a static read-only field of the class. The following is an excerpt from MSDN's description of the static constructor:

Static constructors (C # Programming Guide)

Static constructors are used to initialize any static data, or to perform specific actions that need to be performed only once. The static constructor is called automatically before the first instance is created or any static members are referenced.

MSDN Connection Address: HTTP://MSDN.MICROSOFT.COM/ZH-CN/LIBRARY/K9X6W0HC (vs.80). aspx

Sample code:

Certificate is "certificate Class"

Certificatetypes is a generic collection of "certificate type" types

Certificatedictionary is a dictionary, the key is the certificate type ID, and the value is a collection of certificates under the corresponding certificate type

public static class certificate
{
public static readonly ilist<certificatetype> certificatety pes = new list<certificatetype> ();
public static readonly idictionary<int, ilist<certificatelist>> certificatedictionary = new Dictionar Y<int, ilist<certificatelist>> ();

private static readonly icertificate dal = dataaccess.createcertificate ();

Static certificate ()
{
Certificatetypes = dal. Getcertificatetypes ();
foreach (Certificatetype item in certificatetypes)
{
Certificatedictionary.add (item.id, D Al. Getcertificatelistbycertificatetypeid (item.id));
}
}
}

The problem with the program: Since the data was compiled, it didn't have anything to do with the database. (Interested friends can trace through the SQL Sever Profiler, the new name of the profiler in SQL Server 2005 is SQL Server Profiler in other words, if China turns Japan into a 35th province one day, you add Japan to the Province List database table and you need to recompile the application to show it. What I know now is that you can recompile the application by trying to change the time item of the Web.config file, such as overwriting it once (restart application will lose all sessions, please use caution). Which friend has a good way to get the application to restart automatically by programming it back to me, huh?

Summary: If your team has the time to hard-code the code structure similar to the national list of counties and cities such a collection will not need to use the database, the above solution is not suitable for you. The point to be explained is that the method above is also a hard coded construct collection.

Want to be useful to you