Model View Controller
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
class ArticleDetails
{
public
string Title;
public
string Description;
}
public
class DBArticles
{
// This method returns all articles
public DataSet
GetArticles()
{
string
connectionString = (string)
ConfigurationSettings.AppSettings["ConnectionString"];
DataSet ds =
SqlHelper.ExecuteDataset(connectionString,CommandType.StoredProcedure,"GetArticles");
return ds;
}
}
}
|
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