Introduction
This article shows a very basic approach for designing a scalable, maintainable, and extensible web application using ASP.NET and OOP.
Defining the Base Classes for the Application
It's very common for web applications to have some valid user authentication while accessing pages. The authorization and authentication can be set in the web.config file for the application. To be more intuitive, we can think of it as having some base Secured Web Page class which can handle the validation and log on without the developer having to handle the code for the validation on each page that is developed. (And also, we can have a Non Secured Page Base class from which the non-secured pages in the application can be derived from). To implement this approach, declare a class as follows:
public class SecuredWebPage: System.Web.UI.Page{
public SecuredWebPage()
{}
public void OnInit( System.Web.UI.Page Page)
{
if (Page.Session["CustomSession"] == null)
{
Page.Response.Redirect ("LogOn.aspx?CallingPage=" + Request.RawUrl );
}
}
}
public class NonSecuredWebPage: System.Web.UI.Page
{
public NonSecuredWebPage()
{}
public void OnInit(System.Web.UI.Page Page)
{
if (Page.Session["GenericSession"] == null)
{
GenericSession genericSession = new GenericSession();
genericSession.User = "Ananymous";
Page.Session["GenericSession"] = genericSession;
}
}
The above two classes accept the Web UI Page as the argument on the Init event and checks for a valid session, and either redirects or sets the values as needed. Checking for a valid session can be completely customized as per business needs. But to have a more robust session which is more organized and maintainable, we can have a session class defined and set the appropriate properties of the class and store the class in session.
For example, we can store user login name / password / ID / connection strings etc. in the session.
Defining the Session Class
public class CustomSession
{
private string mstrUser = "";
private string mstrPassword = "";
public CustomSession()
{}
public string User
{
get{ return mstrUser;}
set {mstrUser = value;}
}
public string Password
{
get {return mstrPassword;}
set {mstrPassword = value;}
}
}
public class GenericSession
{
private string mstrUser = "";
public string User
{
get{ return mstrUser;}
set {mstrUser = value;}
}
}
In the session class, there are two classes: one for all the secured session information and the other for generic session information if any needed on non-secured pages. This session class can be extended to add connection string information / access level information, and so forth. All these session values will be set while the user logs on to the application.
The pages in the application will be inherited either from the secured web page or from the non-secured web page.
The secured web page sample code is given below:
Defining the Web pages in the Application
public class WebForm1 : Ez.SecuredWebpage{
private void Page_Load(object sender, System.EventArgs e)
{
CustomSession customSession = (CustomSession) Session["CustomSession"];
Response.Write ("The Page is logged on with User - ");
Response.Write(customSession.User);
Response.Write ("<BR>");
Response.Write ("and the password is ");
Response.Write (customSession.Password);
}
override protected void OnInit(EventArgs e)
{
base.OnInit(this);
}
}
public class WebForm3 : Ez.NonSecuredWebPage
{
private void Page_Load(object sender, System.EventArgs e)
{
GenericSession genericSession =
(GenericSession) Session["GenericSession"];
Response.Write ("The Page is a non secured " +
"page logged on with User - ");
Response.Write(genericSession.User);
}
override protected void OnInit(EventArgs e)
{
base.OnInit(this);
}
}
Through the above approach, web pages, if derived from any of the two base page classes that are defined, will handle the session and the log on. Developers don't have to have the code for checking the valid credentials and redirecting to the log on pages on all the pages in the application. This approach not only handles the navigation of pages from the application, but will also handle the logic if the user tries to access a page in the application by typing in a URL. The log on page used in this example is an ASPX page derived from the default System.Web.UI.Page. That will handle the validation for the log on and save the appropriate session. The code used in this sample just sets the custom session properties.
Expanding the Design Scope Across Many Applications
If the web project is to handle many applications, the above approach can be extended to have applications in a separate folder and the base class and session in a common folder. The individual projects can have their own intermediate base class which derives from the base class described above. When the base class is invoked from different applications, we can set the attributes for the class, and depending on the attribute values that are set, the base class can be modified to set the session properties that should be uniquely available for the application accessed. For example, if from one application you are moving to a page in another application which requires a different access level or different connection to the database, that can be handled here. And the user can be redirected to the page or log on page as necessary.
And also, more the number of applications and pages, it's always better to have a more modularized approach in the design. For example, have all the utility access code like file I/O or Registry access defined in a common folder of the project and reference it in the individual applications. That way, all the similar code will be in one place. For data access, even if we are using straight ADO, just encapsulate the code in a class and access that class from the application. That way, we will have a base set for OOP and we can customize everything in class (for example, we can implement filling the dataset in the class), and the calling code will have to just call that function without having to have all the code for filling the ADO dataset.
The above approach is an effort to define a scalable, maintainable web application implementing OOP. Depending on your needs, this approach can be modularized more, and complex web applications can be developed with very little effort.
Conclusion
The above approach is an effort to define a scalable, maintainable web application development pattern implementing OOP. Depending on the needs, as explained above, this approach can be modularized more, and developing complex web applications can be achieved with very little effort. The complete source code used in the sample application is attached in the link. This sample doesn't implement any complicated code. It provides the approach that can be considered while designing web applications.
