We are interested in extending the ApplicationContext object so that we can throw in some application-related properties and give our application code access in a concise unified manner but we are struggling to figure out how to do this.
We've done something similar in the past with the HttpApplication class by creating our own class, inheriting from HttpApplication and reassigning the Global class (Global.asax) to inherit from our class rather than System.Web.HttpApplication. Only problem is that I really don't know how it works. What I mean is that asp.net/IIS control instantiating the object, so there was nothing to making this happen other than injecting ourself into the existing mechanism.
We'd like to be able to do a similar thing so that when we call ApplicationContext we are actually getting an instance of our class, inherited from ApplicationContext, and exposing our additional properties.
A perfect example of what we want to add are additional configuration properties and settings that are not part of the framework but for the application instead.
Any thoughts?
The mechanism for doing this is to put your app-specific object into one of the ApplicationContext collections (GlobalContext, LocalContext, ClientContext).
The challenge is that ApplicationContext itself never moves (from client to server or back). Only the collections it contains are moved (or not, in the case of LocalContext).
Now ApplicationContext itself is a static class/Module - which explains why it doesn't move - but also means that you can't subclass it...
However, you could create a new static class/Module and have it delegate to ApplicationContext - then just use yours instead of the CSLA one. Since all the methods/properties are, by definition, Shared/static, this technique should work very nicely, with no real performance overhead.
Very simple... just do something like this:
public static class ClientGuid
{
public const string ClientGuid_Key = "ClientGuid";
/// <summary>
/// Gets the GUID of this client.
/// </summary>
/// <value>The this client.</value>
public static Guid ThisClient
{
get { return (Guid) Csla.ApplicationContext.ClientContext[ClientGuid_Key]; }
}
}
Then in my code, I can get type-safe access to the client's GUID simply by using
ClientGuid.ThisClient
whether I'm at the client or the server.
This code assumes that at some point in the past I've put a GUID into the ClientContext collection on the ApplicationContext - you could just as easily provide a set method as well.
HTH
Craig
kids_pro:
However this approach seem to work well in the ASP.NET app until I login in the Csla.ApplicationContext.ClientContext[ClientGuid_Key] become null reference.
I don't know what happen but I found that the code in Global.asa
As I said in a previous post, ClientContext only flows from client to app server, not the other direction.
But if you are in a web setting for the "client", it is important to remember that ASP.NET is stateless. Very clearly nothing you keep on a thread or in HttpContext survives from page request to page request - that's the nature of ASP.NET.
I suggest you use Session, the user's profile, or reload the lang setting on each page request using a ReadOnlyBase-derived object.
Copyright (c) Marimer LLC