Monday, November 29, 2010
Friday, November 19, 2010
OOPS!!
Inheritance and Polymorphism .
1. Inheritance
2. Polymorphism
Early Binding and Late Binding
Running this application produces the following output:
An animal is fed here.
A Lion is fed here.
A Snake is fed here
An animal is fed here.
An animal is fed here.
What has actually happened here is that the Feed() method is bound to the animals
at compile time. This is called early binding. There is no chance to examine the actual
type of animal before feeding it. We would like the compiler to not bind the method
and allow the runtime to bind it instead. That is called late binding and is used to create
polymorphic methods.
In order to overcome the problem outlined in the previous section, we use two keywords,
virtual and override. The virtual keyword is used on the base-class method and
indicates that the method can be overridden. The override keyword is used on the derived-
class method. It means that we intend to change the behavior of the method that is
inherited.
class Animal
{
virtual public void Feed()
{
System.Console.WriteLine ("An animal is fed here.");
}
}
class Lion: Animal
{
override public void Feed()
{
System.Console.WriteLine ("A Lion is fed here.");
}
}
class Snake: Animal
{
override public void Feed()
{
System.Console.WriteLine ("A Snake is fed here."); }
}
class Test
{
public static void Main()
{
Animal a = new Animal();
a.Feed(); // "An animal is fed here."
Lion Leo = new Lion();
Leo.Feed(); // "A Lion is fed here."
Snake Viktor = new Snake();
Viktor.Feed(); // "A Snake is fed here."
}
}
Now we get the behavior we want:
A Lion is fed here.
A Snake is fed here.
1. Inheritance
Class Animal
{
int legs;
int color;
int sound;
}
class Lion:Animal
{
int teeth;
}
class Snake:Animal
{
int length;
}
2. Polymorphism
Early Binding and Late Binding
class Animal
{
public void Feed()
{
System.Console.WriteLine ("An animal is fed here.");
}
}
class Lion: Animal
{
new public void Feed()
{
System.Console.WriteLine ("A Lion is fed here.");
}
}
class Snake: Animal
{
new public void Feed()
{
System.Console.WriteLine ("A Snake is fed here.");
}
}
class Test
{
public static void Main()
{
Animal a = new Animal();
a.Feed(); // "An animal is fed here."
Lion Leo = new Lion();
Leo.Feed(); // "A Lion is fed here."
Snake Viktor = new Snake();
Viktor.Feed(); // "A Snake is fed here."
}
}
class Test
{
public static void Main()
{
Animal[] animals = new Animal[2]; // declare an Animal array
animals[0] = new Lion(); // Add specific animals
animals[1] = new Snake();
for (int i = 0; i < 2; i++)
animals[i].Feed(); // Feed the animals
}
}
Running this application produces the following output:
An animal is fed here.
A Lion is fed here.
A Snake is fed here
An animal is fed here.
An animal is fed here.
What has actually happened here is that the Feed() method is bound to the animals
at compile time. This is called early binding. There is no chance to examine the actual
type of animal before feeding it. We would like the compiler to not bind the method
and allow the runtime to bind it instead. That is called late binding and is used to create
polymorphic methods.
In order to overcome the problem outlined in the previous section, we use two keywords,
virtual and override. The virtual keyword is used on the base-class method and
indicates that the method can be overridden. The override keyword is used on the derived-
class method. It means that we intend to change the behavior of the method that is
inherited.
class Animal
{
virtual public void Feed()
{
System.Console.WriteLine ("An animal is fed here.");
}
}
class Lion: Animal
{
override public void Feed()
{
System.Console.WriteLine ("A Lion is fed here.");
}
}
class Snake: Animal
{
override public void Feed()
{
System.Console.WriteLine ("A Snake is fed here."); }
}
class Test
{
public static void Main()
{
Animal a = new Animal();
a.Feed(); // "An animal is fed here."
Lion Leo = new Lion();
Leo.Feed(); // "A Lion is fed here."
Snake Viktor = new Snake();
Viktor.Feed(); // "A Snake is fed here."
}
}
Now we get the behavior we want:
A Lion is fed here.
A Snake is fed here.
Wednesday, November 3, 2010
Query to get retreive a query in a session
DECLARE @sqltext VARBINARY(128)
SELECT @sqltext = sql_handle
FROM sys.sysprocesses
WHERE spid = (sessionid)
print @sqltext
SELECT TEXT
FROM sys.dm_exec_sql_text(@sqltext)
GO
SELECT @sqltext = sql_handle
FROM sys.sysprocesses
WHERE spid = (sessionid)
print @sqltext
SELECT TEXT
FROM sys.dm_exec_sql_text(@sqltext)
GO
list of the tables from the sql server database
SELECT *
FROM sys.tables
GO
The script above provides various information from create date to file stream, and many other important information. If you need all those information, that script is the one for you. However, if you do not need all those information, I suggest that you run the following script:
EXEC sys.sp_tables
GO
The script above will give all the tables in the table with schema name and qualifiers. Additionally, this will return all the system catalog views together with other views. This Stored Procedure returns all the tables first in the result set, followed by views.
Even though Stored Procedure returns more numbers of rows, it still performs better than the sys.table query.
FROM sys.tables
GO
The script above provides various information from create date to file stream, and many other important information. If you need all those information, that script is the one for you. However, if you do not need all those information, I suggest that you run the following script:
EXEC sys.sp_tables
GO
The script above will give all the tables in the table with schema name and qualifiers. Additionally, this will return all the system catalog views together with other views. This Stored Procedure returns all the tables first in the result set, followed by views.
Even though Stored Procedure returns more numbers of rows, it still performs better than the sys.table query.
List of all the Views from Database in SQL Server
SELECT SCHEMA_NAME(schema_id) AS schema_name
,name AS view_name
,OBJECTPROPERTYEX(OBJECT_ID,'IsIndexed') AS IsIndexed
,OBJECTPROPERTYEX(OBJECT_ID,'IsIndexable') AS IsIndexable
--,*
FROM sys.views;
,name AS view_name
,OBJECTPROPERTYEX(OBJECT_ID,'IsIndexed') AS IsIndexed
,OBJECTPROPERTYEX(OBJECT_ID,'IsIndexable') AS IsIndexable
--,*
FROM sys.views;
Get Column names from SQL Server Database
use database_name
Sp_help table_name
This stored procedure gives all the details of column, their types, any indexes, any constraints, any identity columns and some good information for that particular table.
Second method:
select column_name ‘Column Name’, data_type ‘Data Type’, character_maximum_length ‘Maximum Length’ from information_schema.columns where table_name = ‘table_name’
Sp_help table_name
This stored procedure gives all the details of column, their types, any indexes, any constraints, any identity columns and some good information for that particular table.
Second method:
select column_name ‘Column Name’, data_type ‘Data Type’, character_maximum_length ‘Maximum Length’ from information_schema.columns where table_name = ‘table_name’
Wednesday, October 27, 2010
Web deployement with VS2010
http://blogs.msdn.com/b/webdevtools/archive/2009/02/04/web-deployment-with-vs-2010-and-iis.aspx
Visual Studio 2010 - Web Development Overview
Visual Studio 2010 - Web Development Overview
Web Development Futures with Visual Studio 2010 from Vishal Joshi on Vimeo.
Wednesday, October 20, 2010
InformIT: Using Web Forms > Setting Up Global Objects with the global.asax File
Setting Up Global Objects with the global.asax File
InformIT: Using Web Forms > Setting Up Global Objects with the global.asax File
InformIT: Using Web Forms > Setting Up Global Objects with the global.asax File
Facade Design Pattern
Manage ASP.NET Session Variables using the Facade Design Pattern
http://www.codeproject.com/KB/aspnet/session_facade.aspx
Reduce bugs in ASP.NET applications by improving access to Session variables
Introduction
Just about every ASP.NET application needs to keep track of data for a user's session. ASP.NET provides the HttpSessionState class to store session-state values. An instance of the HttpSessionState class for each HTTP request is accessible throughout your application using the static HttpContext.Current.Session property. Access to the same instance is made simpler on every Page and UserControl using the Session property of the Page or UserControl.
The HttpSessionState class provides a collection of key/value pairs, where the keys are of type String and the values are of type Object. This means that Session is extremely flexible and you can store just about any type of data in Session.
But (there is always a but) this flexibility does not come without a cost. The cost is the ease with which bugs can be introduced into your application. Many of the bugs that can be introduced will not be found by unit testing, and probably not by any form of structured testing. These bugs often only surface when the application has been deployed to the production environment. When they do surface it is often very difficult, if not impossible, to determine how they occurred and be able to reproduce the bug. This means they are very expensive to fix.
This article presents a strategy to help prevent this type of bug. It uses a Design Pattern called a Facade, in that it wraps the very free interface provided by the HttpSessionState class (that can meet the requirements of any application) with a well designed and controlled interface that is the purpose built for a specific application. If you are not familiar with Design Patterns or the Facade pattern, a quick internet search of "facade design pattern" will provide you with plenty of background. However, you do not have to understand design patterns in order to understand this article.
The example code shown in this article is written in C#, but the concepts are applicable to any .NET language.
What is the Problem?
In this section of the article, I will describe the problems with direct access to the HttpSessionState class, without the facade. I will describe the kinds of bugs that can be introduced.
The following shows the typical code written to access session-state variables.
Collapse
// Save a session variable
Session["some string"] = anyOldObject;
// Read a session variable
DateTime startDate = (DateTime)Session["StartDate"];
The problems arise from the flexible interface provided by HttpSessionState: the keys are just strings and the values are not strongly typed.
Using String Literals as Keys
If string literals are used as the keys, the string value of the key is not checked by the compiler. It is easy to create new session values by simple typing errors.
Collapse
Session["received"] = 27;
...
Session["received"] = 32;
In the code above, two separate session values have been saved.
Most bugs like this will be identified by unit testing – but not always. It may not always be apparent that the value has not changed as expected.
We can avoid this kind of bug by using constants:
Collapse
private const string received = "received";
...
Session[received] = 27;
...
Session[received] = 32;
No Type Checking
There is no type checking of the values being stored in session variables. The compiler cannot check correctness of what is being stored.
Consider the following code:
Collapse
Session["maxValue"] = 27;
...
int maxValue = (int)Session["maxValue"];
Elsewhere the following code is used to update the value:
Collapse
Session["maxValue"] = 56.7;
If the code to read the "maxValue" session variable into the maxValue int variable is executed again there will be an InvalidCastException thrown.
Most bugs like this will be identified by unit testing – but not always.
Re-using a Key Unintentionally
Even when we define constants on each page for the session keys, it is possible to unintentionally use the same key across pages. Consider the following example:
Code on one page:
Collapse
private const string edit = "edit";
...
Session[edit] = true;
Code on a second page, displayed after the first page:
Collapse
private const string edit = "edit";
...
if ((bool)Session[edit])
{
...
}
Code on a third, unrelated, page:
Collapse
private const string edit = "edit";
...
Session[edit] = false;
If the third page is displayed for some reason before the second page is displayed, the value may not be what was expected. The code will probably still run, but the results will be wrong.
Usually this bug will NOT be picked up in testing. It is only when a user does some particular combination of page navigation (or opening a new browser window) that the bug manifests.
At its worst, no one is aware that the bug has manifested, we may just end up modifying data to an unintended value.
Re-using a Key Unintentionally - Again
In the example above, the same data type was stored in the session variable. Because there is no type checking of what gets stored, the problem of incompatible data types can also occur.
Code on one page:
Collapse
Session["FollowUp"] = "true";
Code on a second page:
Collapse
Session["FollowUp"] = 1;
Code on a third page:
Collapse
Session["FollowUp"] = true;
When the bug manifests, there will be an InvalidCastException thrown.
Usually this bug will NOT be picked up in testing. It is only when a user does some particular combination of page navigation (or opening a new browser window) that the bug manifests.
What Can We Do?
The First Quick Fix
The first and most simple thing we can do is make sure we never use string literals for session keys. Always use constants and so avoid simple typing mistakes.
Collapse
private const string limit = "limit";
...
Session[limit] = 27;
...
Session[limit] = 32;
However, when constants are defined locally (e.g. at page level), we might still re-use the same key unintentionally.
A Better Quick Fix
Rather than define constants on each page, group all session key constants into a single location and provide documentation that will appear in Intellisense. The documentation should clearly indicate what the session variable is used for. For example, define a class just for the session keys:
Collapse
public static class SessionKeys
{
///
/// The maximum ...
///
public const string Limit = "limit";
}
...
Session[SessionKeys.Limit] = 27;
When you need a new session variable, if you choose a name that has already been used you will know this when you add the constant to the SessionKeys class. You can see how it is currently being used and can determine if you should be using a different key.
However, we are still not ensuring consistency of data type.
A Much Better Way - Using a Facade
Only access the HttpSessionState from within one single static class in your application - the facade. There must be no direct access to the Session property from within code on pages or controls, and no direct access to HttpContext.Current.Session other than from within the facade.
All session variables will be exposed as properties of the facade class.
This has the same advantages as using a single class for all the session keys, plus the following advantages:
Strong typing of what gets put into session variables.
No need for casting in code where session variables are used.
All the benefits of property setters to validate what gets put into session variables (more than just type).
All the benefits of property getters when accessing session variables. For example, initialising a variable the first time it is accessed.
An Example Session Facade Class
Here is an example class to implement the Session facade for an application called MyApplication.
Collapse
///
/// MyApplicationSession provides a facade to the ASP.NET Session object.
/// All access to Session variables must be through this class.
///
public static class MyApplicationSession
{
# region Private Constants
//---------------------------------------------------------------------
private const string userAuthorisation = "UserAuthorisation";
private const string teamManagementState = "TeamManagementState";
private const string startDate = "StartDate";
private const string endDate = "EndDate";
//---------------------------------------------------------------------
# endregion
# region Public Properties
//---------------------------------------------------------------------
///
/// The Username is the domain name and username of the current user.
///
public static string Username
{
get { return HttpContext.Current.User.Identity.Name; }
}
///
/// UserAuthorisation contains the authorisation information for
/// the current user.
///
public static UserAuthorisation UserAuthorisation
{
get
{
UserAuthorisation userAuth
= (UserAuthorisation)HttpContext.Current.Session[userAuthorisation];
// Check whether the UserAuthorisation has expired
if (
userAuth == null ||
(userAuth.Created.AddMinutes(
MyApplication.Settings.Caching.AuthorisationCache.CacheExpiryMinutes))
< DateTime.Now ) { userAuth = UserAuthorisation.GetUserAuthorisation(Username); UserAuthorisation = userAuth; } return userAuth; } private set { HttpContext.Current.Session[userAuthorisation] = value; } } ///
/// TeamManagementState is used to store the current state of the
/// TeamManagement.aspx page.
///
public static TeamManagementState TeamManagementState
{
get
{
return (TeamManagementState)HttpContext.Current.Session[teamManagementState];
}
set
{
HttpContext.Current.Session[teamManagementState] = value;
}
}
///
/// StartDate is the earliest date used to filter records.
///
public static DateTime StartDate
{
get
{
if (HttpContext.Current.Session[startDate] == null)
return DateTime.MinValue;
else
return (DateTime)HttpContext.Current.Session[startDate];
}
set
{
HttpContext.Current.Session[startDate] = value;
}
}
///
/// EndDate is the latest date used to filter records.
///
public static DateTime EndDate
{
get
{
if (HttpContext.Current.Session[endDate] == null)
return DateTime.MaxValue;
else
return (DateTime)HttpContext.Current.Session[endDate];
}
set
{
HttpContext.Current.Session[endDate] = value;
}
}
//---------------------------------------------------------------------
# endregion
}
The class demonstrates the use of property getters that can provide default values if a value has not been explicitly stored. For example, the StartDate property provides DateTime.MinValue as a default.
The property getter for the UserAuthorisation property provides a simple cache of the UserAuthorisation class instance, ensuring that the instance in the session variables is kept up to date. This property also shows the use of a private setter, so that the value in the session variable can only be set under the control of facade class.
The Username property demonstrates a value that may once have been stored as a session variable but is no longer stored this way.
The following code shows how a session variable can be accessed through the facade. Note that there is no need to do any casting in this code.
Collapse
// Save a session variable
MyApplicationSession.StartDate = DateTime.Today.AddDays(-1);
// Read a session variable
DateTime startDate = MyApplicationSession.StartDate;
Additional Benefits
An additional benefit of the facade design pattern is that it hides the internal implementation from the rest of the application. Perhaps in the future you may decide to use another mechanism of implementing session-state, other than the built-in ASP.NET HttpSessionState class. You only need to change the internals of the facade - you do not need to change anything else in the rest of the application.
Summary
The use of a facade for HttpSessionState provides a much more robust way to access session variables. This is a very simple technique to implement, but with great benefit.
http://www.codeproject.com/KB/aspnet/session_facade.aspx
Reduce bugs in ASP.NET applications by improving access to Session variables
Introduction
Just about every ASP.NET application needs to keep track of data for a user's session. ASP.NET provides the HttpSessionState class to store session-state values. An instance of the HttpSessionState class for each HTTP request is accessible throughout your application using the static HttpContext.Current.Session property. Access to the same instance is made simpler on every Page and UserControl using the Session property of the Page or UserControl.
The HttpSessionState class provides a collection of key/value pairs, where the keys are of type String and the values are of type Object. This means that Session is extremely flexible and you can store just about any type of data in Session.
But (there is always a but) this flexibility does not come without a cost. The cost is the ease with which bugs can be introduced into your application. Many of the bugs that can be introduced will not be found by unit testing, and probably not by any form of structured testing. These bugs often only surface when the application has been deployed to the production environment. When they do surface it is often very difficult, if not impossible, to determine how they occurred and be able to reproduce the bug. This means they are very expensive to fix.
This article presents a strategy to help prevent this type of bug. It uses a Design Pattern called a Facade, in that it wraps the very free interface provided by the HttpSessionState class (that can meet the requirements of any application) with a well designed and controlled interface that is the purpose built for a specific application. If you are not familiar with Design Patterns or the Facade pattern, a quick internet search of "facade design pattern" will provide you with plenty of background. However, you do not have to understand design patterns in order to understand this article.
The example code shown in this article is written in C#, but the concepts are applicable to any .NET language.
What is the Problem?
In this section of the article, I will describe the problems with direct access to the HttpSessionState class, without the facade. I will describe the kinds of bugs that can be introduced.
The following shows the typical code written to access session-state variables.
Collapse
// Save a session variable
Session["some string"] = anyOldObject;
// Read a session variable
DateTime startDate = (DateTime)Session["StartDate"];
The problems arise from the flexible interface provided by HttpSessionState: the keys are just strings and the values are not strongly typed.
Using String Literals as Keys
If string literals are used as the keys, the string value of the key is not checked by the compiler. It is easy to create new session values by simple typing errors.
Collapse
Session["received"] = 27;
...
Session["received"] = 32;
In the code above, two separate session values have been saved.
Most bugs like this will be identified by unit testing – but not always. It may not always be apparent that the value has not changed as expected.
We can avoid this kind of bug by using constants:
Collapse
private const string received = "received";
...
Session[received] = 27;
...
Session[received] = 32;
No Type Checking
There is no type checking of the values being stored in session variables. The compiler cannot check correctness of what is being stored.
Consider the following code:
Collapse
Session["maxValue"] = 27;
...
int maxValue = (int)Session["maxValue"];
Elsewhere the following code is used to update the value:
Collapse
Session["maxValue"] = 56.7;
If the code to read the "maxValue" session variable into the maxValue int variable is executed again there will be an InvalidCastException thrown.
Most bugs like this will be identified by unit testing – but not always.
Re-using a Key Unintentionally
Even when we define constants on each page for the session keys, it is possible to unintentionally use the same key across pages. Consider the following example:
Code on one page:
Collapse
private const string edit = "edit";
...
Session[edit] = true;
Code on a second page, displayed after the first page:
Collapse
private const string edit = "edit";
...
if ((bool)Session[edit])
{
...
}
Code on a third, unrelated, page:
Collapse
private const string edit = "edit";
...
Session[edit] = false;
If the third page is displayed for some reason before the second page is displayed, the value may not be what was expected. The code will probably still run, but the results will be wrong.
Usually this bug will NOT be picked up in testing. It is only when a user does some particular combination of page navigation (or opening a new browser window) that the bug manifests.
At its worst, no one is aware that the bug has manifested, we may just end up modifying data to an unintended value.
Re-using a Key Unintentionally - Again
In the example above, the same data type was stored in the session variable. Because there is no type checking of what gets stored, the problem of incompatible data types can also occur.
Code on one page:
Collapse
Session["FollowUp"] = "true";
Code on a second page:
Collapse
Session["FollowUp"] = 1;
Code on a third page:
Collapse
Session["FollowUp"] = true;
When the bug manifests, there will be an InvalidCastException thrown.
Usually this bug will NOT be picked up in testing. It is only when a user does some particular combination of page navigation (or opening a new browser window) that the bug manifests.
What Can We Do?
The First Quick Fix
The first and most simple thing we can do is make sure we never use string literals for session keys. Always use constants and so avoid simple typing mistakes.
Collapse
private const string limit = "limit";
...
Session[limit] = 27;
...
Session[limit] = 32;
However, when constants are defined locally (e.g. at page level), we might still re-use the same key unintentionally.
A Better Quick Fix
Rather than define constants on each page, group all session key constants into a single location and provide documentation that will appear in Intellisense. The documentation should clearly indicate what the session variable is used for. For example, define a class just for the session keys:
Collapse
public static class SessionKeys
{
///
/// The maximum ...
///
public const string Limit = "limit";
}
...
Session[SessionKeys.Limit] = 27;
When you need a new session variable, if you choose a name that has already been used you will know this when you add the constant to the SessionKeys class. You can see how it is currently being used and can determine if you should be using a different key.
However, we are still not ensuring consistency of data type.
A Much Better Way - Using a Facade
Only access the HttpSessionState from within one single static class in your application - the facade. There must be no direct access to the Session property from within code on pages or controls, and no direct access to HttpContext.Current.Session other than from within the facade.
All session variables will be exposed as properties of the facade class.
This has the same advantages as using a single class for all the session keys, plus the following advantages:
Strong typing of what gets put into session variables.
No need for casting in code where session variables are used.
All the benefits of property setters to validate what gets put into session variables (more than just type).
All the benefits of property getters when accessing session variables. For example, initialising a variable the first time it is accessed.
An Example Session Facade Class
Here is an example class to implement the Session facade for an application called MyApplication.
Collapse
///
/// MyApplicationSession provides a facade to the ASP.NET Session object.
/// All access to Session variables must be through this class.
///
public static class MyApplicationSession
{
# region Private Constants
//---------------------------------------------------------------------
private const string userAuthorisation = "UserAuthorisation";
private const string teamManagementState = "TeamManagementState";
private const string startDate = "StartDate";
private const string endDate = "EndDate";
//---------------------------------------------------------------------
# endregion
# region Public Properties
//---------------------------------------------------------------------
///
/// The Username is the domain name and username of the current user.
///
public static string Username
{
get { return HttpContext.Current.User.Identity.Name; }
}
///
/// UserAuthorisation contains the authorisation information for
/// the current user.
///
public static UserAuthorisation UserAuthorisation
{
get
{
UserAuthorisation userAuth
= (UserAuthorisation)HttpContext.Current.Session[userAuthorisation];
// Check whether the UserAuthorisation has expired
if (
userAuth == null ||
(userAuth.Created.AddMinutes(
MyApplication.Settings.Caching.AuthorisationCache.CacheExpiryMinutes))
< DateTime.Now ) { userAuth = UserAuthorisation.GetUserAuthorisation(Username); UserAuthorisation = userAuth; } return userAuth; } private set { HttpContext.Current.Session[userAuthorisation] = value; } } ///
/// TeamManagementState is used to store the current state of the
/// TeamManagement.aspx page.
///
public static TeamManagementState TeamManagementState
{
get
{
return (TeamManagementState)HttpContext.Current.Session[teamManagementState];
}
set
{
HttpContext.Current.Session[teamManagementState] = value;
}
}
///
/// StartDate is the earliest date used to filter records.
///
public static DateTime StartDate
{
get
{
if (HttpContext.Current.Session[startDate] == null)
return DateTime.MinValue;
else
return (DateTime)HttpContext.Current.Session[startDate];
}
set
{
HttpContext.Current.Session[startDate] = value;
}
}
///
/// EndDate is the latest date used to filter records.
///
public static DateTime EndDate
{
get
{
if (HttpContext.Current.Session[endDate] == null)
return DateTime.MaxValue;
else
return (DateTime)HttpContext.Current.Session[endDate];
}
set
{
HttpContext.Current.Session[endDate] = value;
}
}
//---------------------------------------------------------------------
# endregion
}
The class demonstrates the use of property getters that can provide default values if a value has not been explicitly stored. For example, the StartDate property provides DateTime.MinValue as a default.
The property getter for the UserAuthorisation property provides a simple cache of the UserAuthorisation class instance, ensuring that the instance in the session variables is kept up to date. This property also shows the use of a private setter, so that the value in the session variable can only be set under the control of facade class.
The Username property demonstrates a value that may once have been stored as a session variable but is no longer stored this way.
The following code shows how a session variable can be accessed through the facade. Note that there is no need to do any casting in this code.
Collapse
// Save a session variable
MyApplicationSession.StartDate = DateTime.Today.AddDays(-1);
// Read a session variable
DateTime startDate = MyApplicationSession.StartDate;
Additional Benefits
An additional benefit of the facade design pattern is that it hides the internal implementation from the rest of the application. Perhaps in the future you may decide to use another mechanism of implementing session-state, other than the built-in ASP.NET HttpSessionState class. You only need to change the internals of the facade - you do not need to change anything else in the rest of the application.
Summary
The use of a facade for HttpSessionState provides a much more robust way to access session variables. This is a very simple technique to implement, but with great benefit.
Subscribe to:
Posts (Atom)