The beauty of MVC (article/technology)

You can download the sources: Sources

Introduction

I have two very "dear" design/architectural patterns, that I carry around with me in all projects, technologies, boundaries. I might say "their usage should be enforced by law". Just kidding :) One of them is MVC, the other is n-tier/layered architectures, so I decided to share why I like about the first and how I explain it to my friends and coworkers.

Why should we use MVC?

I noticed that most programmers when asked why do they use a method of separating the data (model) from the user interface (view), cannot give unambiguous answers. Some would just say: because it is a good practice or ... because Martin Fowler (or the java) world recommends it. In my opinion this answer is wrong. Wrong because, a technology that is not understood can be easily misused.

So why?

In my opinion each action should, at least try, to have a goal. The goal of this separation (ui from data) is achieving the other goal of delivering the customer, useful software fast. Now let's get back to the each (as each framework, technology etc describes that using it you can deliver faster:)) and explain why.

-debugging is much easier. Firstly, because by having two files, you can watch the code easier, because it is smaller, and you get tired just from scrolling. Secondly, and more important, because you know what happens where, you can track bugs easier.

-changes can be done easier. You can change some logic without affecting the ui, or change the UI (if you're really good you can even go from web to desktop or the other way round:))

-extensions are welcome - this will bring benefits too (I am sure you can make your client pay:))

Going back to the roots

I remember when I started programming and I had to do all kings of very simple programs to solve a simple problem. Sometimes not even programs, just algorithms and pseudo-code. Nothing displaying a "hello world" MessageBox, nothing mixed with either UI of database (persistence code). Well, let's go back to that.

The simplest program I can think of is one that computes a sum, of two given numbers:

public class Sum
{
private int a = 0;
private int b = 0;
private int result = 0;

public void Compute()
{
result = a+b;
}

public int A
{
get{return this.a;}
set{this.a = value;}
}
public int B
{
get{return this.b;}
set{this.b = value;}
}
public int Result
{
get{return this.result;}
}

}

It could have been solved just be making a static method, buy I wanted to use properties. I will show you why later.

Now this is our simple program, but of course the user has to have a form of using it, so an UI is needed. Let's try a Windows.Forms approach, like this:

Screenshot

In it we will have an instance (reference) sum of Type Sum the databinding code :

this.txtA.DataBindings.Add("Text",sum,"A");
this.txtB.DataBindings.Add("Text",sum,"A");
this.txtResult.DataBindings.Add("Text",sum,"Result");

and the button is clicked:

this.sum.Compute();

Now, everything works. Just as simple I could add the UI for ASP.NET.

The controller

Now, we have exposed Sum as the model, and we have seen the view. What's the controller for?

In some cases you don't want to mix UI interface create/layout etc code with the code that actually handles the user events. You could just make a class to do that, and include there all UI logic code.

One advice, don't let the model know about the view or controller. If you really need to do something that can't be resolved through the controller or data-binding, user events that are raised by the model and captured and processed in the controller. Another advice is that you shouldn't forget that the model is in the UI layer. Make it communicate/use/encapsulate classes (datasets etc) from the business layer.

Steps in applying MVC

First listen to what the user wants in that form then you adopt one of these strategies:

1. Bottom up - code the model as if it were the simple program that I told you about, then add an interface to it
2. Top down - design the interface with the user, when he's ok about it, think about a simple program that can handle the data you send from the UI designed and be able to send the result back.

I would recommend using both, depending on the situation.

Conclusion

So the beauty of MVC in my opinion is that it allows me to see software like a game of mind again, as when I started developing, and not like something completely automatic, where you act like a machine dragging and dropping controls, datasets, adapters etc and seeing them work. MVC is one of those things in software that when applied is both beneficial technically and mentally. It is beautiful :)