To MVC or not to MVC?

Back in the old days, when I worked on windows desktop applications, I did a lot of programming with OWL and MFC (ok, after my pre-petzoldian and petzoldian periods, so I'm that old!). On those days, both class libraries supported MFC implementations (probably not as isolated as possible, but for the sake of this article, MVCs).

On those days, we called that implementation Doc/View. And after they arrived, managing MDI MFC applications without CDocument and CView was no longer an option. And imagine implementing an OLE2 compliant application on OWL (in my case, it was a workflow editor) without TOleView. Doc/View was a earned right, and we don't easialy give up earned rights...

Then came the internet, and my cosy programming world was turned upside down. So I did some CGI applications in good old C and C++ (I should probably have chosen Perl, but I have this thing about scripting...), and throw away my good old MVCs.

Then came ASP. For most that I hated the VB idiom and limitations, it made all the difference. I was still miles away from my MVC (man, I even lost most of my OO goodies), but things were getting better.

Then came .NET, and I understood what Moses must have felt when leaving the desert! I had most of my good old OO goodies back! And something that was less an MVC than the old MFC implementation, but that worked like a charm!

This paradigm was a simple, very well tested and proven model used in successful developing environments. It had it roots in great developing environments like Turbo Pascal and Turbo C, later refined in Turbo Pascal for Windows, Visual C++, Visual Basic and C++ Builder. But the MVC is still missing...

The question any ASP.NET architect is asking is: how (and when) to implement an MVC? First, let me point what I feel lacking in the present model:

• Firstly, the model just doesn't exist. Well, at least it isn't enforced, most programmers do represent it, but the articulation with the View and Controller is weak and optional.

• Then, the controller logic is hardly reusable.

• Finally, the presentation logic is untestable. Well, this remains a MVC limitation - the MVP pattern handles this problem.

So what is the solution? Microsoft p&p answer is MVPC (Model-View-Presenter with Controller) is the way to do it. From WCSF documentation:

Separate the responsibilities for the visual display and the event handling behavior into different classes, the view and the presenter. The view class (the Web page) manages the controls on the page, and it forwards events to a presenter class. The presenter contains the logic to respond to the events, and in turn, manipulates the state of the view. The presenter class uses the model (frequently, this is application state that is represented by business entitles) to determine how to respond to the events.

The presenter manipulates the view when the model changes and it updates the model as the user interacts with the view. To retrieve and update the model, the presenter interacts with domain business logic. The domain logic should be the same for all types of presenters. (The presenter can call the domain but not vice-versa.) To achieve this, you create a controller. The controller interacts with data sources (for example, through a data access layer) and contains presentation-independent business logic (for example, workflow.)

For much that I agree, I know that most people will consider it an overkill. And for most simple projects, it will be.

One thing's for sure: until MVC (or MVPC) is supported out-of-the-box in Visual Studio, the majority of people probably won't use it.