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.