ASP.NET Fundamentals : Part 1 : ASP.NET Architecture

July 11, 2012 by Abhi·Comments Off

This line of tutorials will take you through all the ASP.NET fundamentals

Architecture of ASP.Net

How an ASP.NET page is processed?

All the asp.net pages are parsed into a class definition and that class is then compiled into a.Net assembly who sole purpose is respond to request destined for the endpoint. This class is then loaded into the worker process i.e. w3wp.exe and the classes will then be created and will process the requests. These classes are created on demand and this happens for all the .aspx. So it’s safe to say that when you are writing an .aspx you are writing a class. So essentially when we are writing aspx we are just building additional classes and extending the base classes and controlling the class generation from .aspx files.

Let’s see this in action. I hope you have IIS installed on your machine. So just go to cà inetpub à wwwroot and create text file named HelloWorld.aspx and add the following content to it.

<html>
<h1> Hello World!!! </h1>
</html>

And then save it and close it. Now go to the Internet Explorer and type the following:

http://localhost/helloworld.aspx

And you will see something like below:

HelloWorld.aspx

Now let’s understand what going on here. Let’s first add the code as shown below to the HelloWorld.aspx. The Page Directive will set the language as C# and also the Debug to true. Also we will access the GetType().Assembly.Location method as we know we are in .NET and we will be able to track the location of the class.

<%@ Page Language="C#" Debug="true" %>
<html>
<h1> Hello World !!! </h1>
<h3> This Page is loaded from
<%= GetType().Assembly.Location %>
</html>

The %= is the evaluation syntax in the server side script <%= GetType().Assembly.Location %>

Now when you will refresh the page, you could see the location from where the assembly was loaded along with the name of the assembly.

Temporary ASP.NET Files

Now when we open up this directory (E:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\a2cc4162\951dc92c)

Temporary ASP.NET Files Directory

you could see that C# source code files are present here and if you open them you could see the class definition present in it. As you could see the name of the class is created by replacing the . with an _ and it derives from System.Web.UI.Page which is the base class for all the aspx pages.

ASP.NET generated Code file

Now if we scroll down the file we could see how the html is parsed and the method that we wrote injects the content.

ASP.NET generated Code file

Dynamic Content

Now as we could see in the image below, we could see Interspersed script notation which is root cause of many problems in a web site so we do not want to follow this as a practice at all. This syntax is still supported but we will try to move towards other techniques for easier to maintain code.

ASP.NET Dynamic Content

So the types of dynamic content that we can integrate onto our page is

Interspersed server-side script – So this is the way of dropping code onto the page but the language will be as specified in the page directive. It has to be in the language specified at the top of the page. Then we also have the evaluation syntax (GetDisplayItem) which is equivalent to Response.Write.
Server side scripts – So we can also include server side scripts as a block with the Runat sever attribute so that it is dumped into the class definition.

Let’s just add the following code to the HelloWorld.aspx from the previous example.

<%@ Page Language="C#" Debug="true" %>
<script runat="server">
const int _itemCount = 10;
string GetDisplayItem(int n)
{
    return "item #" + n.ToString();
}
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Dynamic Content</title></head>
<body>
<h1> Hello World !!! </h1>
<h3> This Page is loaded from
<%= GetType().Assembly.Location %></h3>
<ul>
<% for (int i=0;i<_itemCount; i++)
{ %>
<li><%=GetDisplayItem(i)%></li>
<% } %>
</ul>
<%
Response.Write("<h2>Total Number of items = "
+ _itemCount.ToString() + "</h2>");
%>
</body>
</html>

When we run the page we would see something like below:

ASP.NET Server Side Script

Let’s go back to the directory and have a look at the generated content once again. So what we see here is that the server side code is injected directly into the code file. So whenever we use server side scripting then that is dropped into the class directly. So we used put only those things in server side scripting that would make sense if they are in the class definition directly. So we could not directly executable code in class definition.

Generated server side script ASP.NET

And the client code is added to the function definition that will write onto the screen. So the code that was part of Interspersed script is put directly into a function within our class. We could not define function here as nested function definition is not allowed in C#.

Generated server side script ASP.NET

Server Side Controls

We should avoid using Interspersed scripts as it tends to clutter pages and makes the code difficult to maintain. We should try to use the preferred model for dynamic content in an ASP.NET page. This model comes from the server side controls in ASP.NET. So any control that has a runat=”server” attribute will be added to the class definition as a server side member variable, so we could manipulate these variable instead of the Interspersed scripts. The state maintained for the Server side controls is implicitly POST to the same page.

Let’s revisit our page and replace the server side scripts with server side controls. Let’s first replace the dynamic generated script with the server side control definition. We are following a common technique of populating the server side control with some content even though this content will never be displayed. So we are using a server side control named bulleted list which will display an unordered list.

ASP.NET Server Side Controls

Now we are going to write a method to populate this list. So we are overriding the OnLoad method which we inherited from the page base class. So we are using the already created list _displayList and clearing the items in it. Then we are iterating through the items and add the items to the _displayList.

ASP.NET Server Side Controls

If you will run this page now you will get an error saying that the runat=”server” controls should be placed in the form with a runat=”server” attribute. So let’s add that.

ASP.NET Server Side Controls

And now we run the page we will something like below.

ASP.NET Server Side Controls

Let’s also have a look at the class definition changes with the addition of the server side controls. The very first thing that you will notice is that the BulletedList named _displayList is added as a protected member. And the interaction with that _diasplayList member is shown below it.

ASP.NET Server Side Controls

Data Binding

In the previous section we edited the server side control at very low level but we can also use ASP.NET data binding model. So we will add a string array of the items we want to show. It has to be an Enumerable collection. It can be an array, dataset, datatable, strongly typed list class, etc. So all we need to do is the ItemsSource property to the collection we want to bind to and then exclusively call DataBind(). Let’s see the code of the same.

ASP.NET Data Binding

We will see a similar output if we run this page but instead of iterating and adding the items we have utilized the power of data binding.

Declarative Data Binding

Version 2.0 of .NET introduced data source controls. The idea behind declarative data binding is that instead of manually writing the code for data binding we hand it off to another control. In this case we will have a look at the ObjectDatSource as this lets us point the datasource to a class definition. To use it we have to specify the name of the class to use and the name of the method that will be used to retrieve the data. So now our page will not have any data access code as all that logic is separated to a separated class. So let’s write the code for this. Let’s go to the wwwroot folder and create a directory named App_Code. This is a special directory because if we place any source code files in this directory they will be implicitly complied if they are referred any of our pages. We will then add a file named ItemsDataSource.cs

ASP.NET Declarative Data Binding

We will remove all the server side code as it will be handled by this declarative data source. And then let’s wire up to the ItemsDataSource. We have added an object data source as MyDataSource and refer it in the BulletedList. So now when the list needs the data it will go and query the mentioned object data source which will in turn query the specified method in the specified class.

ASP.NET Declarative Data Binding

Code Behind V2.0

The ASP.NET version 2.0 code behind model is like shown below. We have specified in our aspx page the code behind for this page. Also we have the concept of partial class implemented for these classes.

ASP.NET Code Behind

Let’s change our code accordingly. Let’s add a new file names hellocodebehind.aspx.cs and move our code which not related to the presentation to this file.

ASP.NET Code Behind

Page Lifecycle

So now we have the ability to separate the code from the view as we saw in the previous section. Let’s understand the ASP.NET page lifecycle which is shown in the image as below. This will help us understand many other things that can be done inside the page class definition. Just refer the aspx.cs class that we wrote earlier and you will see that we have overridden the OnLoad event of the page. This is one of the events that take place while processing the request for the page and this is most common of the events in which users generally tap into for doing data binding modifying controls and there values. There are many other events that occur during the complete page request process as we could see in the image below. When a request for an aspx page is made then class is constructed and its constructors will be called and then this lifecycle sequence is launched starting from the top left to the bottom right. Another event for which handler is added is very commonly is Init. This event occurs early in the lifecycle of the page but after all the controls have been loaded into the control tree. Another event is the LoadComplete event which is fired after all the server side events have been fired. Pre render is a back stop which takes place just before the rendering is sent to the client. PreInit is the only event where we can edit master pages and themes. Render event occurs when the response is sent back to the client. Once the response is sent back to the client then Unload events occurs.

ASP.NET Page Lifecycle

Event Handling

Let’s talk about how we can wire up events. This is the techniques that can be used to wire up all the events in the page class. The naming convention for such events is On followed by the name of the event.

protected override void(EventArgs e)
{
    base.OnLoad(e);
}

In Visual studio the standard techniques when using Visual Studio is to create a function named Page_ followed by the name of the event and .Net will implicitly add a delegate subscription. This function is called as the Auto Event Wire Up and this is the preferred model in Visual Studio.

protected void Page_Load(object sender, EventArgs e)
{
}

Another way of accessing this events is to access these events as the members of the Page class. Simply .NET events defined on the System.Web.UI.Page Base class and all we need to do is use += to add a delegate.

this.Load += new EventHandler(EventPage_Load);
this.Load += EventPage_Load;
void EventPage_Load(object sender, EventArgs e)
{
}

So let’s see this in action. Let’s modify the HelloWorldCodeBehind.aspx to use the AutoEventWireUp.

ASP.NET Event Handling

Now let’s make use of Auto Event Wire up and tap into the LoadComplete event. We need to modify the HelloWorldCodeBehind.aspx.cs for this as below.

ASP.NET Event Handling

When we run this page we will see that the text is written at the top of the page.

Method Name for Implicit event subscription

The way AutoEventWireUp wire works is through the hashtable defined in the .NET. At runtime a check is made for the strings present in the code to match up with the string shown in the table below. So there is no algo for. So it’s just a set of hard wired strings that are looked for automatically when AutoEventWireUp property is set to true. This will work only if the signature also matches up with the event.

ASP.NET Event Handling

Control Event Handling

Other events that we will be handling in code are the events are raised by the controls on the page. So the recommended model for handling a control initiated event is go to the server side control in the view and add a prefix On to the event name and then set the handler for it. That handler in the code should have the correct signature of an event.

<asp:Button ID="ClickMeButton_Click" runat="server" Text="Click me!" onClick="_clickMeButton_Click" />

protected void ClickMeButton_Click(object sender, EventArgs e)
{
}

The other way to do it is use the += notation the code class to specify the handler for a particular event.

Let’s see this in action. Add a button and a label at the bottom of the HelloWorldCodeBehind.aspx file as shown below.

ASP.NET Control Event Handling

Now let’s go to the server side code i.e. HelloWorldCodeBehind.aspx.cs and add a handler for this button click event.

ASP.NET Control Event Handling

When we run the page we will see something like below.

ASP.NET Control Event Handling

Compilation

Another feature that was added to .NET 2.0 was the suite of directories as shown below.

App_Code directory is the place where we place the code and it automatically compiles as part of the aspx page request process.
App_Browsers directory is used for defining additional .browser files which define the additional browser capabilities.
App_GlobalResources directory automatically compiles .resx files into the application.
App_LocalResources directory automatically compiles .resx files into the application.
App_Themes directory is used for referencing themes in the site
App_WebReferences directory is where wsdl files are placed.

The version 2.0 ships with a new compiler named aspnet_compiler.exe which helps us compile our directories manually into binary deployment files. Below is the detailed chart of all the directories and there usages.

ASP.NET Compilation

Shadow Copying

The mechanism of shadow copying is import for the deployment, updating, etc. The idea behind it is this that we do not have to shut the site to deploy the new binaries. In classic ASP we need to shut down the server in order to release the references so that we can copy the new binaries without any errors. With version 2.0 we do not have to do that because of Shadow copying. As we can see in the diagram below when we try to access a binary what ASP.NET does is physically copies the binary to an obfuscated location and then runs so that there is no direct reference to the binary and also when the binary is updated then it updates the binary as well.

ASP.NET Shadow Copying

You can find the code for this post here.

Any questions, comments and feedback is most welcome.

Silverlight 4 : View Models and MVVM

July 9, 2012 by Abhi·Comments Off

Hey guys,

In this post i am going to talk about the most import part of the Silverlight and WPF applications, the View Model and the MVVM pattern.

UI development Challenges

View Models are designed to solve certain problems that pop during the UI designing.

The major problem is that the User Interface code is difficult to test especially with automated tests. This is because the Code behind lives in the UI. Suppose we want to test a method in a code behind file like MainPage.xaml.cs then we have no other choice but to make an instance to the MainPage class, so when we do that the constructor is called will call InitializeComponent() and it will load all the xaml controls which will make the copy of the User Interface tree available and this a major problem in Unit Testing because some components might not work correctly till they are displayed as they make assumptions about the messaging and event handling. So the behavior of MainPage might be different from what it would have been at runtime.
Another problem with code behind is that big and complex classes which are really difficult to maintain and are not flexible. You can easily get used to using the code behind for you code because that’s where Visual Studio adds the event handlers automatically. The best approach for coding is to have well defined classes with narrow responsibilities.
The code behind job is to interact with the User Interface objects but when we start to add behaviors in the code behind which interact with User Interface objects we give our classes a wider scope and that’s the start of problems. It becomes all the more problematic when the application logic starts to integrate with the User Interface elements and the state of the application is saved with the help of user Interface elements.
Another reason for the problem is overdoing the Data Binding. When you application logic starts depending on your Data Binding states. One example that comes to mind is that when the validation rules are made dependent on Data Binding which should actually always be the part of our application logic.

Separated Presentation

This is the technique which is recommended for overcoming the problems mentioned above. By using separated presentation we can avoid xaml codebehind by removing user interface manipulation logic in code behind, interaction logic in code behind, application logic in code behind and everything else not required in code behind. The best thing to do is to keep as less as code as possible in the xaml code behind. Keep any kind of application logic in a separate class which is generally named as Model. So we should make the model only concerned with the application which says what the application does and not how the user interacts with the application. Now UI class should not have any of the interaction logic because of the problems I described in the previous section so we need to create another class which will hold the interaction logic. This is the View Model. This governs any non-trivial logic. It will have the logic for the User Interface to behave the way we want it to behave.

Model View View Model

So let’s talk about each component.

Model – A model is a classic model which comprises of the C# classes. It has not reference to the user interface and is not aware of the existence of any User Interface. The Model classes are compileable without any reference to the User Interface classes. The types in the Model consist of the concepts our application works with. If should be able to take these classes to any console application, web application or windows application and they should be able to compile with no problems. During the design of the Model we need to take decisions on how will the model be used? For example we situations where the Model is shared by both the client and the server or the model can mostly stay in the server or the model can completely stay in the client.
View – View is generally a User Control. In Silverlight it is a good idea to split up the user interface into multiple User Controls.
View Model – For each View we write a View Model. So the main purpose of the existence of a View Model is to serve the View. It’s possible for a particular view model to span into multiple classes. The bottom line is that the View model serves the purpose of presenting data or screen to your application. The reason it’s called a view model because adapts a particular model for the specific view. Like the model, the view model is a C# class and is not required to derive from a particular class. Sometimes it makes sense to make a base view model and derive from the same but the pattern does not demand that. But unlike Model it can use Silverlight types in its properties. The important things that define the View Model is that the information flows between View and ViewModel via Data Binding and this enables ViewModel to change the View without having to depend on the view. This is very useful for testability as we can instantiate the ViewModel without having to create the View. We can just use the View Model and invoke the methods and get the values back for testing.

Let’s see some code now.

Create a new Silverlight application. And create 3 folders in the Solution Explorer named Model, Views and ViewModel.

Silverlight 4 : Model View View Model

Let’s add a couple of classes in the Models folder. Add 2 new classes named UserModel and MessageModel to the Models folder and add the content as below.

Silverlight 4 : Model View View Model

To increase the abstractions lets add a new folder in the solution named services and add an interface to it named IModelProvider and add the following code to it. This abstraction will make testing easier for us.

IModelProvider

Let’s add another class named ModelProvider.cs in the services folder which will be dummy data provider for this sample application. Add the following code to this class.

ModelProvider

The way we will handle user input in this application is via commands. .NET provides an interface named ICommand which gives us abilities on a User Action – Invoke and Enabled. ViewModels often provide commands through properties because it provides an option to connect the button to the view model without needing any code in the code behind. It is a good approach if you want a way to enable or disable the availability of command as anyways there will be a property exposed to the view by the view model. So it makes a lot sense to use one property to handle the enabling and invoking a command via one property. Silverlight does not implement icommand. Only button and Hyperlink are able to user ICommand but we need to implement it in our code. Let’s add a new class named RelayCommand inherting from ICommand. This will be the relay the action to the method of our choice. We can also refer this as a delegate command as we use a delegate a to specify the method to invoke. Let’s add the following code to the RelayCommand.

Relay Command

In the Views folder let’s create new viewmodels. Create a new class named MessageItemViewModel.cs and add the following code to it. It’s the job of the view model to provide the data to be displayed. The all message view model will create one of these for each item in the page. So it will not only require a reference to the model provier but also the particular message which it will wrap. We will add three properties which will extract the MessageAuthor, Message Title, Message Body from the underline model object.

MessageItemViewModel

Let’s add another ViewModel for all available messages name AllMessagesViewModel. The view model asks the provider for all the available messages and then wraps each one into the message item view model. So that the view can have an items control which can have a list of the items.

AllMessagesViewModel

Now let’s create the View for the ViewModels that we have created. Create a new UserControl named MessageItemView.xaml. let’s first add a reference to ViewModels

xmlns:vm=”clr-namespace:ViewModelSample.ViewModels”

Also set the reference of the DataContext to the MessageItemViewModel. The d: here represents that this data context is design time and will not be effective at runtime so we need specify that later as well.

d:DataContext=”{d:DesignInstance vm:MessageItemViewModel}”

Now add the following code to the MessageItemView.xaml. This will contain the per message user interface.

MessageItemView

Let’s another View which will be the home for the View that we just created. Let’s name this view as AllMessagesView.xaml and add the following code in the xaml. This view just contains a ItemsControl inside scrollviewer and this items control just has a item template as the MessageItemView. It will create an item view for each message item.

AllMessagesView

Also let’s add the following code in the code behind for this.

AllMessagesView

Finally add the following code to your MainPage.xaml.

MainPage.xaml

The code of this post is available here.

Any questions, comments or feedback is most welcome.

Expression Blend 4 : User Controls

July 3, 2012 by Abhi·Comments Off

In this section we will see how we can break our pages into small pieces by the use of User Controls. If you have worked even once on Silverlight you will see that UserControl is the root Element. So whenever a Silverlight application is displayed in a browser then the first thing that a browser does instantiates the Root UserControl of the start page of the Silverlight application. A User Control can have any number of layout containers in it, it has its own code behind and has an entire system that builds an application. This is concept is extended by Silverlight by moving the pieces of the user control and moving them to the individual documents.

Create a new Silverlight application Expression Blend. In the UserControl add 4 girds and in each grid add a rectangle and give that rectangle a different fill from the others.

Expression Blend 4 : Grids

Now right click on the 1^st grid and select Make Into User Control. Build the solution.

Expression Blend 4 : User Control

We will see that the our application MainPage is still the samebut if we see the Objects and timeline the grid that we converted to User Control is replaced the UserControl. Also we will see and exclamation mark. Once we build our project it goes away.
Now if we go and change something in the user control we will see that the change is appearing in the MainPage but with and exclamation mark stating that something has changed.
But you may need to pay attention when you are working with resources and user Controls. Let me tell you what exactly I am talking about. Just Select a TextBlock and drag it onto the Blue Rectangle.

Expression Blend 4 : Text Blocks

Type some text into the textblock. Come out of the edit mode by pressing ctrl + Enter. Now scroll down to the Text properties of the TextBlock and select the Font as Broadway and Font Size as 20 pt.

Expression Blend 4 : Font Family

Now click on the property marker next to the Font Family and select Convert to new resource. Name it as MyFont.

Expression Blend 4 : Font Family Resource

Now let’s go ahead and create another text block in the Green user Control. Now try to use the local resources while the text of the textblock is selected. We will notice that while we are in edit mode we cannot create or use resources.

Expression Blend 4 : Font Family Resource

Now let come out of the edit mode and select the local resource MyFont to set the font of the Shopping Cart.

Expression Blend 4 : Font Family Resource

If we place a textblock on the user control and try to use local Resource MyFont than it is not available because we have saved that MyFont as the local resource in the MainPage document.

Expression Blend 4 : Font Family Resource

Now lets add another text block to the bottom grid and use the local Resource MyFont.

Expression Blend 4 : Local Resource

Now let’s make the bottom grid into a user control and now we will see that the Textblock still is using the MyFont resource.

Expression Blend 4 : Local Resource

Now lets go to the resources tab and expand the UserControl and we will see that the MyFont Resource is present there.