I have seen many articles written about this subject for .NET. The problem is that there is something wrong or left out of all of them. Most demonstrate the pattern properly but leave some important information out when it comes to an actual implementation. In the example below, I show you how to create a useful singleton business object class which will load data from the database, persist itself within the application, account for inserts and updates properly, only allow one instance of itself and have the ability to be reloaded.
A singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. This can be extremely useful in a .NET Web application. In a typical Web application, every time a user requests a page a transaction is sent to the database, the database returns the data, the data is then read into an object and then displayed. If there is one user on your site, then this happens once, but if there are thousands of users on your site at once this is happening thousands of times. This means thousands of requests to your database and thousands of processor ticks constructing and deconstructing your objects all for the same exact data!
In the example below, the data is loaded from your database the first time it is requested and stored at the application level. This means that all of your users will use the same data, no need for constant round trips back to the database. It also counts for the need to update and insert data, as well as the ability to reload your data as need be.
Using the Code
As a base, we start by inheriting a
generic dictionary of a fictional business object article. We choose the
dictionary object because it allows us to index to specific objects by their key. We never need to loop through our collection to find an object if we know the id.
Another thing to note is the use of the
SyncLock, the reason this is there is because there is a possibility that a user will try to load data while another user is loading it. The lock only allows one instance of that code to be run at once, all others wait in queue. The second test will allow the users in queue to pick up the object after it has been loaded.
Lastly you will notice that there are two methods named
addarticle. The use of these methods will both insert the data into your singleton object as well as the database, thus not forcing you to reload your object and allowing your data to be safe and secure in the database ready for the next reload.
Public Class ArticleList
Inherits Generic.Dictionary(Of Integer, Aricle)
Private Shared ReadOnly SyncLock_LOCK As New Object()
Private Shared m_instance As ArticleList
Public Shared ReadOnly Property Instance() As ArticleList
If m_instance Is Nothing Then
If m_instance Is Nothing Then
m_instance = LoadData()
System.Web.HttpContext.Current.Application("CacheTime") = _
Private Sub New()
Private Shared Function LoadData() As ArticleList
Dim al As New ArticleList()
Using reader As SqlClient.SqlDataReader = _
Dim a As New Aricle()
Catch ex As Exception
Public Sub AddArticle(ByVal key As Integer, ByVal value As Aricle)
Public Sub EditArticle(ByVal key As Integer, ByVal value As Aricle)
m_instance(key) = value
Public Shared Sub ReloadData()
m_instance = Nothing
Points of Interest
This is a nice alternative to using
web.caching to persist data in memory and should give your Web application that boost it was looking for. Just please be aware that if you try to load 300 megs of memory into a singleton object your ASP.NET worker process will take a dive. Design your applications carefully and make the best choices based on your situation.