Having worked with .NET Remoting for a while, I would like to describe an issue I encountered while working with Client Activated Objects (CAO's) hosted in IIS.

This article describes how you can avoid a matching instance of a class in every remote object to ensure it only has one instance and to provide a global point of access to it.

For the purpose of clarity, let us take a sample scenario and consider that you are designing a distributed application as depicted in the picture below.  You have a Web Server hosting the Presentation Tier of your solution, an Application Server hosting the Business Tier of your solution, and a Back Office Server hosting your solution database.

Figure 1

To do so, you will be creating a .NET solution with at least 2 projects: an ASP.NET Web Application project and a Class Library project.  A website is created on the Web Server to host the Web Application files.  Another website is created on the Application Server to host the Class Library assemblies supposing here that your remote server is IIS.

On the Web Server you are probably going to use the Application State to store public information, for example, all DataTables that you might use to bind the drop-down lists available in your web pages (Countries, Departments, Titles, Currencies, etc.).

Let us call Combos the class responsible for retrieving the information from the database and fill the corresponding DataTable objects stored into the Remote Object.  The Remote Class has many children classes, Combos being one of them.  We call Remote Object an instance of the Remote Class.

Until now, everything does fine.  However, what if you called a method in your Business Tier and passed to it the DepartmentId as an argument and the method is supposed to compose en email for the department manager?  Where do you get the DepartmentManagerName and the DeparmentManagerEmail fields from?

·         The method into the remote object cannot read the DataTables in the Application State of the Web Server.

·         You cannot pass all that you need as arguments because the list of arguments can grow depending on what you are doing.

·         You would not like to open a connection to the database on each method call passing the DepartmentId as parameter.

Many solutions to this problem can be found; the one below may not be the best, but it suits me well.  Some developers may instantiate the Combos class in each Remote Object.  I find this solution to be resource consuming.

What I would do is to create a single instance of Combos shared by all remote objects created on the Application Server.  The way to do so is to apply the Singleton Design Pattern to this class. Here is a sample showing how this can be done.

In the Business Tier you will be defining the Combos class as listed in Listing 1.

Listing 1

Public Class Combos
    Inherits MarshalByRefObject
 
    Private Shared _Instance As Combos

     Public Shared ReadOnly Property Instance() As Combos
        Get
             'Using lazy instantiation
            If _Instance Is Nothing Then _Instance = New Combos

             Return _Instance
        End Get
    End Property
 
    'Note that the constructor method is Protected (it can be Private)
    Protected Sub New()
        'Write some code here
    End Sub
 
End Class

As you can see, if it exists, an instance of Combos is accessed by all Remote Objects through the Instance property.  If it does not exist, a new (and unique) instance of Combos will be created and returned through the same Instance property.

In the Presentation Tier all you need to do is to call the Instance property and assign its return value to a variable of type Combos as shown in Listing 2.

Listing 2

Private Sub GetCountries()
  Dim Cbo As Combos = Combos.Instance
   ddlCountries.DataSource = Cbo.GetCountries()
   ddlCoutries.DataTextField = "CountryName"
   ddlCountries.DataValueField = "CountryId"
  ddlCountries.DataBind()
End Sub

For many applications the Singleton Design Pattern approach works fine.  However, for multithreaded applications this approach proves to have a potentially hazardous side effect.  If two threads manage to enter the control block at the same time, two instances of the member variable could be created.  To solve this you might be tempted to merely place a critical section around the control block in order to guarantee thread safety.

However, ASP.NET runs each incoming request on its own separate worker thread.  The ASP.NET programming model is based on a scheme in which each worker thread is routed through a private set of ASP.NET objects, including applications, modules, pages, and custom handlers.  The ASP.NET programming model was designed to ensure that only one worker thread will ever touch any one of these objects at any one time.  This enhances productivity because you can write most of your ASP.NET code as single-threaded.  There is no need to worry about concurrency or thread safety for the scenario described in this article.

In most of the cases we can use the Singleton Pattern design in our Business Tiers the same way we use the Application State in our Presentation Tiers to consume less resources.