Model View Controller Pattern by azamsharp

February 9, 2010 muthu Application Blocks 0

Introduction:

Before you even think of writing a simple line of code you must architect the application so that if behaves as you expect it to. If you start building the application without making the architecture first than you may face many problems that will be very difficult to handle. A good application must have a strong and solid architecture. In this article I will present you a common pattern known as Model View Controller. This model is extensively used in a multi-tier applications. By using the model view controller pattern you can make applications that are more scalable and well developed.

What is Model View Controller?

  • The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes [Burbeck92]:
  • Model. The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
  • View. The view manages the display of information.
  • Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.

Some of the benefits of using Model View Controller:

  • Supports multiple views. Because the view is separated from the model and there is no direct dependency from the model to the view, the user interface can display multiple views of the same data at the same time. For example, multiple pages in a Web application may use the same model objects. Another example is a Web application that allows the user to change the appearance of the pages. These pages display the same data from the shared model, but show it in a different way.
  • Accommodates change. User interface requirements tend to change more rapidly than business rules. Users may prefer different colors, fonts, screen layouts, and levels of support for new devices such as cell phones or PDAs. Because the model does not depend on the views, adding new types of views to the system generally does not affect the model. As a result, the scope of change is confined to the view. This pattern lays the foundation for further specializations of this pattern such as Page Controllerand Front Controller.
  • Complexity. The MVC pattern introduces new levels of indirection and therefore increases the complexity of the solution slightly. It also increases the event-driven nature of the user-interface code, which can become more difficult to debug.
  • Cost of frequent updates. Decoupling the model from the view does not mean that developers of the model can ignore the nature of the views. For example, if the model undergoes frequent changes, it could flood the views with update requests. Some views, such as graphical displays, may take some time to render. As a result, the view may fall behind update requests. Therefore, it is important to keep the view in mind when coding the model. For example, the model could batch multiple updates into a single notification to the view.

Application without Model View Controller approach:

Lets see an application that is made without the Model View Controller approach. In this article I will keep the application limited to one page so that the user can understand the purpose of the MVC pattern. Our application will consist of a button with text “display”. When the button is clicked the datagrid in the application is filled with data from the database. You user interface will look something like this:

Now we want to implement the code. We want that when the button is clicked the datagrid is populated with some data from the database. Lets implement this without using the Model View Controller approach.
The button click code will look something like this:

private void Button1_Click(object sender, System.EventArgs e)
{

SqlDataAdapter ad = new SqlDataAdapter("SELECT Title,Description FROM Articles",connection);
   DataSet ds = new DataSet();
   ad.Fill(ds,"Person");
   myDataGrid.DataSource = ds;
   myDataGrid.DataBind();

}


1) First we make the data adapter object. Then we used the Ad-Hoc query to iterate through the database.
2) We made the dataset object and filled it with the result of the query
3) Next we assign the datagrid source property to the dataset
4) And finally we bind the datagrid on the screen.
if you run this application and click on the button you will see the correct result. I have used the article table in my application which displays the article title and the description. Lets see what are the problems of using this approach.

Problems using this approach:

1) First of all we have no layering. The user is communicating directly with the database by the click of a button. Every enterprise application should be made in layers. The layers separate the user interaction with the business logic.
2) We are using Ad-Hoc queries. Which sets the database open for SQL Injections. We should always use stored procedures since stored procedures can be cached and hence increase the speed of database operations.

using the Model View Controller Approach to solve the problem:

Now lets see how we can make our application more better using the Model View Controller pattern. First of all we make a class, lets name the class DBArticles since we are retrieving data from the Article table in the database.
Your class will look something like this:

using System;
using System.Data.SqlClient;
using System.Data;
using Microsoft.ApplicationBlocks.Data;
using System.Configuration;

namespace ModelViewController
{
// This class maps to the fieds in the database

public string Title;
public string Description;
}

public class DBArticles
{
	// This method returns all articles
	string connectionString = (string) ConfigurationSettings.AppSettings["ConnectionString"];
	DataSet ds = SqlHelper.ExecuteDataset(connectionString,CommandType.StoredProcedure,"GetArticles");
	return ds;
}

public DataSet GetArticles()
{
}

public class ArticleDetails
{
}

There are many points to note here. Lets take each step one by one:
1) We have two classes in our DBArticle class. One is ArticleDetails and other is DBArticles. ArticleDetails has the same fields as that in the database. This is called a class mapping. We use this approach to return the class object whenever needed instead of returning many variables as an array.
2) Second you see that I am using Microsoft Data Access Application Block. By using this block you can really minimize the amount of code that needs to be written to perform common operations.
3) I am using Stored procedures instead of Ad-Hoc queries. The stored procedure in the article will look something like this:

CREATE PROCEDURE [GetArticles] 
SELECT Title,Description FROM Articles; 
GO

4) After the stored procedure is executed I just return the dataset to the caller.
Now lets see the code which calls the GetArticles method.

private void Button1_Click(object sender, System.EventArgs e)
{
DBArticles article = new DBArticles();
myDataGrid.DataSource = article.GetArticles();
myDataGrid.DataBind();
}

Now honestly its this look just beautiful. Maybe later you decide to edit the GetArticles method you only need to change the class library without having to alter the button click code. Lets make it more pretty :).
Until now we were not catching any exceptions so lets write some code to catch exceptions.

public DataSet GetArticles()
{
string connectionString = (string) ConfigurationSettings.AppSettings["ConnectionString"];
try
{
   DataSet ds = SqlHelper.ExecuteDataset(connectionString,CommandType.StoredProcedure,"GetArticles");
}
catch(SqlException sqlEx)
{
// Log the exception
}
catch(Exception ex)
{
// log the exception
}
return ds;
//.......//.....
}

So, now your application is also logging exceptions. The code for the exception handling in each of the block depends how you logg them. You can email the exception, you can write them in a file and you can also write them in database. I don’t like to repeat the code again and again so that’s why make a new class which is dedicated in handling exceptions. Your class can look something like this:

using System;
namespace ModelViewController
{
	public class Exceptions
	{
		public Exceptions()
		{
		}
		public static void LogException(string errorMessage)
		{
		// Logg excetion here
		}
	}
}

Now instead of writing 5-6 lines each and every time you need to log an exception you can just pass the exception to the static method “LogException” which in turn will log the exception.
By using Model View Controller pattern, our class libraries become scalable and also portable. Remember that the user interface keeps on changing if we used the MVC pattern we can change the UI without changing the business logic.
Happy Coding!
References:
Model-View-Controller began as a framework developed by Trygve Reenskaug for the Smalltalk platform in the late 1970s [Fowler03]. The version you have just read references the following works:

[Fowler03] Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.

Attachments:

Project Files: ModelViewController_sample.zip