I was reading in information week about Microsoft’s new MVC framework for .Net. What struck me was that I always associated model-view-controller frameworks with Microsoft. It is a roughly based on a design pattern that I used years ago in developing native Windows applications. It just makes life easier and it is nice to see that Microsoft is now providing it as part of .Net. So what is MVC and how can it be used in almost any application?
The Model-View-Controller framework is designed to create a separation of concerns. You don’t really have to worry about the underlying mechanisms, just the layer that you are working on at the moment. It encapsulates the other stuff so you can focus on the task at hand, whether it is writing a database query (Model), an operating procedure (Controller), or a front end interface(View). This makes things much easier when developing with a team where you have programmers, designers, and database administrators working on the same project. Each can work in their own area of the application. Even for solo projects it makes things much the same reasons, it allows you to be more focused on that area of the application without worrying about the other parts. Its why I like object-oriented programming, you let each part worry about its own details and just create interfaces to expose the parts you need to other objects and methods. In MVC programming you do the same thing, but you essentially have objects for the models (things), controllers (logic), and views (pages, forms, etc.).

If I were to create a simple application that allowed people to sign up for my mailing list I would create the following:

• Subscriber – A model that represents a subscriber to my list
• SubscribeController – A controller that handles subscribing, unsubscribing, and listing subscribers.
• subscribers/subscribe – A view that allows people to signup for the mailing list.
• subscribers/unsubscribe – A view that allows people to opt-out of the mailing list.
• subscribers/list – A view that allows me to see who is currently subscribed.

I would then proceed to create a database, link it up with the model, write my subscribe, unsubscribe, and list functions, and related views. Combine this with using a framework such as Ruby-on-Rails, .Net MVC, QT, or PHP and you can build an application quite quickly.

What I’m finding is that there are benefits to using this design pattern for almost any application development. Currently I am using it to develop 3 completely unique sets of applications.

• An online product catalog – Using CakePHP
• A native GUI application – Using QT
• A client-server application – Using dlib and a custom MVC framework

Even though each of these applications is completely different I can pick up where I left off on any of them and immediately know where everything is because structure is virtually the same. It also allows any other developer familiar with the framework to pick up with development because it promotes good code structure, readability, and separation of concerns. Regardless of what programming language you are comfortable developing in look to see if a MVC framework is available. Even if you don’t switch to a framework you can learn a lot from it. I know I have.