Once you split your application into multiple tiers, you quickly find that the business and data tiers don't (well shouldn't) have direct access to the
object and the
The separation allows you to switch UIs or UI libraries without having to overhaul the engine of the application, and is good for organisation, so it's good practice, but has its hassles.
How do you store ASP.NET application state, such as certain database connection parameters, or a database connection object, if you don't have application to
One way is to use the provider pattern and abstract the state management behind a simple state framework that has two parts.
The first part is a library with a base class and a
property to hold a derived instance of it.
Here's an example of the base state component:
Here's an example of the
property which holds a copy of the state component:
These are in a library which has no reference to
and therefore no way to access
. This state library is at the core of the application and all projects requiring state access should reference it.
Now to actually provide all of those low level components access to the state collections offered by
, we introduce the web specific state component.
The web specific state component inherits
and overrides all of the functions. The web specific state component is defined in the presentation library and passed down to the lower levels to use. This allows them to interact with the
components indirectly by overriding the functions.
Here's an example of the web specific state provider:
Each set of functions corresponds to a specific scope and a different state collection.
, the web state provider component is initialized and assigned to
(if not already initialized).
Here's an example of the initialization call in
, which inherits
and is the code behind for the Global.asax
Here's an example of the initializer:
The initializer above uses modified provider pattern code taken from the MSDN reference and could easily be simplified to just:
StateAccess.State = new WebStateProvider();
So as a result, the library structure is:
library is at the center/base. Pretty much every other library will reference the core
library, which contains the base class and
property to hold it.
The web specific state components are in another library in the web tier either in their own library or within a general web assembly.
Now because of this setup, I can create a
in the data tier and store it using:
Then retrieve it again using:
IObjectServer objectServer = (IObjectServer)StateAccess.State.GetApplication(serverKey);
This is despite the data assemblies having no direct reference to the
library it's being stored in
. This is a good place to store something if you only want a single instance of it for the life of your application.
So the entire project can be switched to a desktop GUI or another UI just by providing a state component for that.
would likely be sufficient for most cases, but a custom one can be provided if needed:
It gets used during testing to remove any dependencies on the System.Web library and HttpContext.Current.
This pattern can be reused for a multitude of situations, with a little imagination. You'll likely need to create code specific to that solution.