Supported by Nova Outsourcing
Object is an instance of a class. In some cases, we prefer to use object directly. Session object is one of the cases.
Let’s say we have a class designed for holding values in the session.
public sealed class SearchCriteria { public int Year { get; set; } public int Month { get; set; } public int SelectTypeID { get; set; } public string SearchMessage { get; set; } public long BookPk { get; set; } public long StartChapter { get; set; } public long EndChapter { get; set; } public long StartVerse { get; set; } public long EndVerse { get; set; } public int SortTypeID { get; set; } } The old code for using the object in the session. Normally, we will wrap the session object with property to facilitate the use of the session object
public SearchCriteria SearchData { get { return (SearchCriteria)Session["SearchCriteria"]; } set { Session["SearchCriteria"] = value; } }
Then use the property as following.
public void SomeMethod() { long bookId = SearchData.BookPk; //... }
The improved code will be more simpler as following. You will find the property goes away.
public void SomeMethod() { long bookId = SessionObjectHelper.Get<SearchCriteria>().BookPk; //... }Why we call it session object? Because the class for the session object is decorated with an unique identifier.
[SessionObject("FD5EDFF6-69F9-4e5e-BC49-1604E40C795F")] public sealed class SearchCriteria{}
Another advantage of the design is that the identifier is a guid which will absolutely avoid naming conflicts in session names.
For more detail, please refer to the source code in DevLib3
SessionObjectAttribute.cs
SessionObjectHelper.cs
Please feel free to let me know if you have any ideas on the design.
Supported by Nova Outsourcing