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 :)

The GAP between what needs to and what is

The gap applied on an agile process: who was guilty?


After being a software developer for more then 4 years, working directly and indirectly with customers, I had the opportunity in the last two months to become a software customer. This experinece was quite beneficial, and "the gap" problem is one of the things I encontered direcly.

Both I and the developer, came in and stayed troughout the project with the best intentions. But there were still missunderstandings, that we successfully overcame but I wanted to get to the bottom of them. Many times, I was very occupied at work so I didn't have the time or was too tired to be able to update specifications, answer to questions in useful time. This disrrupred the main thing affecting any good collaborative project: communication.

Having other more important things to do all day, just increased the gap and might have comporomised the entire project, even between a customer and a client with the best intentions. This was mostly my fault. And probably every customer, thinks (rightfully) that he had nothing to do with the failure, because he had more important things to do.


The closer the customer, the better the software


The customer must make a good compromise between his job and the time he can allocate the developers , to answer questions, kill ambiguity in specifications, give feedback, "steer" the development.

This lack of time, or more urgent things to do in their day to day activity, will always happen with the customers. This is the thing that must be overcome but any agilist, people that try to get the customer involved as much as possible.

Sell this to the customer. The need to be as colose as possible. The need to reorganize some activities in order to be close to you when you need him. Probably this is the hardest thing that must be sold to the customer, along with the software, if you want to embrace an agile methodology, but is well worth it. Afterall, the closer the customer, the better the software.


Conclusion


Even with motivated parties involved in a project, a gap between what must be implemented and what is implemented wil always appear. Keeping this gap, as small as possible cannot be done in a single step, and must probably begin when you first contact the client, "preparing" him that his attention will be very necessary, even though he's got a lot of other more important things to do. Then by using an iterative/incremental development process, applied with small iterations (2-4 weeks), and with frequent releases to the users, that won't let the gap grow, . After all, if you try to cover this gap after 6 months, you might not be able to do it anymore ...