High-Performance .NET Application Development & Architecture

N-TIER

The presentation layer is just that the presentation of the application via a User Interface (UI). It encapsulates our HTML code and any controls or components that make up our entire application. In classic ASP this page would look like a unpleasant interspersion of code, or spaghetti code as it's known. Simply put, this means server, client and HTML code all mixed together without a care in the world.

This approach is messy, problem prone and doesn't follow .NET's Object-Oriented approach. Our .NET page in comparison will be cleanly laid out, and lightly coded. Why? Well, again because of .NET Platform model. How? With .NET's code-behind . Code-Behind is, as its name implies, the method where all your commonly used code is placed in another file, "behind" the page, in a dll or vb/cs source file, that get's inherited via your page's @ Page Directive. Alongside this benefit, there are performance advantages of writing code this way, since .NET automatically pre-compiles these controls!

The page's @ Page Directive inheriting code-behind is thus:

<%@ Page Inherits="myNamespace.ClassName" Src="source file" %>

The source file would look something like this:

          
// Page inherits code-behind source file
          
using System; 
using System.Diagnostics; //For Tracing, Performance Monitoring 
using System.Drawing; // For Graphics, Datagrid Colors 
using System.Web; // For HttpContext 
using System.Web.UI; //For Literal Controls 
using System.Web.UI.WebControls; // For Datagrid
          
          
namespace myNamespace { 
  // All your variables, properties here 
          
  public class ClassName : Page { //Inherits Page Class 
    // All your code here

  } 
}

Above we imported any necessary libraries we might need. Next we created our namespace, and within this our class, which is what our Page's @ Page Directive will inherit for code-behind to work. However, if you prefer for whatever reason, you could simply create a standalone class in your code-behind file, whereby the Page Directive's Inherits attribute is the class name alone, instead in our example where it is "myNamespace.ClassName."

Also notice that our class inherits the Page class, because this is what constitutes our code-behind interaction with our caller page.

Alternatively, if you compile your source code into a dll,

(csc/vbc).exe /t:library /out:c:\inetpub\wwwroot\bin\sf.dll sf.(cs/vb) /optimize

you would then import it and instantiate it, like so:

          
// Import It 
          
<%@ Import Namespace ="myNamespace" %> 
          
// Then Instantiate It 
          
[C#] 
          
ClassName myObjectName  = new ClassName(); 
          
[VB] 
          
Dim myObjectName  As New ClassName()
        

or better yet just xcopy it into your server's main bin folder and declare it from within your page's <script> tags, like so:

 // Import it


[C#]

public myNamespace.ClassName myObjectName = new myNamespace.ClassName();


[VB]

Public myObjectName As New myNamespace.ClassName


// Then instantiate it in your code within a Function or Method


[C#]

ObjectType myVariableName = myObjectName.MethodName(Parameters);


[VB]

Dim myVariableName As ObjectType = myObjectName.MethodName(Parameters)
 

        

Another method that implement's code-behind methodology are pagelets or .NET's new improved include files/ Web Server User Controls , or .ascx files . These files expand on the content (UI)/code separation by including commonly used code, in nicely stored controls, again just like include files in classic ASP, but certainly more powerful. How? Well, they for one they can assign and pass parameters, not to mention handle events!

Apart from the more conventional application of user controls, and normal code-behind modules, yet another instance is in creating reusable, Custom Server Controls . Basically these are new, custom built, super-duper controls, acquiring their functionality from inheriting its target control's base class, and expanding on it. Creating one works along the same lines as the above source code, except instead of a Page code-behind file inheriting the Page Class in that example, you'd inherit your particular control's base class. Take for example creating a custom datagrid control:

          
namespace myNamespace { 
          
   // All your variables, properties here 
          
   public class ClassName : DataGrid { //Inherits DataGrid Class 
          
    // All your code here 
          
   } 
          
}
        

After you compile your source file, you'd then register your assembly for use in your page like so:

          
<%@ Register TagPrefix="myControl" Namespace="myNamespace" Assembly="myDll Name" %>
        

Then implementing it is as easy as:

          
<myControl:myNamespace ID="MyControl ID" runat="server" property1 = "false" _
          
property2 = "Red" OnClick="Click Method Name" />
        

Notice how (providing your source code includes this) your custom control could accept and set, parameters and or properties, and handle events, as we've mentioned. Moreover, this could also apply to standard code-behind user controls as well! Custom control creation tends to get more advanced, and the coding skill requirements jump up a few notches. At any rate, a user controls' more common usage stems, more or less, in reusable site code, i.e. a page's header and footer for instance.

Below demonstrates a typical, albeit, bare bones .aspx page. It has a header and footer, whereby the respective code is separated between two web server controls or modules - header.ascx and footer.ascx. All your page would need to do is register them, and place them in the page accordingly:

          
// The control's first get registered at the top of the page 
          
<%@ Register TagPrefix="Header" TagName="Top" Src="header.ascx" %> 

<%@ Register TagPrefix="Footer" TagName="Bottom" Src="footer.ascx" %> 
          
// Then get placed in your page where needed 
          
<body> 
          
<Header:Top ID="Header" runat="server" /> 
          
<Footer:Bottom ID="Footer" runat="server" /> 
          
</body>
        

Man, .NET rocks! Now that's a nice, clean presentation I think! But wait, that's not all, your web server controls themselves could also further inherit code-behind code! In this case the inherit/src members are implement this time via the control's @ Control directive.

// Header.ascx
          
<% @ Control inherits="ClassName" src="source file" %> 
// Your code here

And your control's code-behind file is identical to your page's code behind file, except the control doesn't inherit the Page class, but rather the UserControl class, since it's a control that's calling this file.

          
// User Control's code-behind source file 
          
using System; 
using System.Web.UI; 
using System.Web.UI.WebControls;

public class ClassName : UserControl { 
          
          
   // Your code here 
}

Additionally, if you compile your code-behind file as a dll with a namespace that looks like this:

          
namespace ClassName { 
          
   public class myClass : UserControl { 
          
   // Your code here 
          
   } 
          
}
        

Then there are now two ways for including it for use in your page. You could inherit it as follows:

          
// Inherit it 
          
<%@ Control inherits="ClassName.myClass" src="source file" %>
        

Or you could import it and instantiate it as demonstrated earlier. Still yet another cool feature in .NET is the ability for the global.asax file to inherit code-behind as well!

<%@ Application Inherits="MyApp" %> 

For more info on the fine art of OOP Programming, it'll be worth your while in taking the time to thoroughly read - The Quick and Dirty .NET Guide to C#/VB Object-Oriented Programming.

As a final afterthought, since a majority of your initial code within your pages and source file will interact on your code's Page_Load method, you may find that aside from this common function, you may to need to process something even before this or something else as well. Well then have a look at these six additional Page methods, that are contiguous to your Page's event handlers:

• Page_Init - for pre-Viewstate processing
• Page_PreRender - for pre-Page rendering tasks.
• Page_DataBind - for when the Page binds data
• Page_Dispose - for when the Page get's disposed
• Page_Error - for any errors on the Page
• Page_Unload - for code to run on Page unloading or exit

So the above are simply just something to keep in mind. Now you should have a real good idea on creating a clean Presentation Layer with the use of web server controls.

Business Rules/Logic Layer:

This layer is quite simple, as it involves all specific and particular business rules and requirements to any given company. It enforces rules pertaining to data that is retrieved from a database, i.e. mathematical, monetary, formatting, etc.

These rules are stored as methods in this layer separately from other components, thus any changes effective to this app would take place only once. Again, these are functions or methods capable of anything required by your application, to effect all particular business practices. Therefore, in light of efficient N-Tier design, you really do want to avoid placing any business logic in your presentation layer, and here is where it would all go.