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.
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.