Introduction
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.
Background
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 editarticle
and 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
Get
If m_instance Is Nothing Then
SyncLock SyncLock_LOCK
If m_instance Is Nothing Then
m_instance = LoadData()
System.Web.HttpContext.Current.Application("CacheTime") = _
DateTime.Now()
End If
End SyncLock
End If
Return m_instance
End Get
End Property
Private Sub New()
End Sub
Private Shared Function LoadData() As ArticleList
Dim al As New ArticleList()
Using reader As SqlClient.SqlDataReader = _
DataAccess.ExecDataReader("sp_someprocedure")
While reader.Read
Try
Dim a As New Aricle()
....
....
al.Add(a.ArticleID, a)
Catch ex As Exception
End Try
End While
End Using
Return al
End Function
Public Sub AddArticle(ByVal key As Integer, ByVal value As Aricle)
MyBase.Add(key, value)
End Sub
Public Sub EditArticle(ByVal key As Integer, ByVal value As Aricle)
m_instance(key) = value
End Sub
Public Shared Sub ReloadData()
m_instance = Nothing
End Sub
End Class
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.