MVC, Design Patterns and Real-Life
June 20th, 2008(This blog post was inspired from a discussion I had with Moti Gust earlier this week, Moti and I have been working jointly on various development projects since early 90’s)
Model-View-Controller (MVC) is a corner stone Design Pattern that in recent years received more and more acceptance. MVC is a “solution” to various problems raised when presentation code, business logic code and data access code are mixed together. MVC separates a UI driven application into three components: View - the presentation code (which renders the contents of the model), Controller - translates between user actions (received through the View) and actions performed by the model and Model - representing the enterprise data / business rules that communicate with the data model. The following image (taken from here) summarizes the concepts in this design pattern:
There are some frameworks that endorse MVC as the proper way to build UI applications, such as (part of the Castle Project) and recently Microsoft has been looking into integrating MVC into the .NET Framework 3.5, lots of info on that around the web, one such link is this.
MVC is a great concept, it provides away to separate between pure UI code, UI logic and application logic. The separation allows the UI developer to be de-coupled from the application logic, all he needs is a good, robust API and to separate between the graphical / rendering part of his presentation code (the View) and the link to the business logic (the Controller). It even allows another developer, who did not originally wrote the rendering part to tie between the model and the presentation. It gives a lot of flexibility. But Dragons be here - is that really the solution we’re looking for?
Before going into the real-life example which flared this whole discussion, I think it’s worth a while to pause and think about Design Patterns. There are many ways to categorize and segment Design Patterns, I won’t get into all that, but if you look the MVC, Publish-Subscribe Design Pattern and Patterns like Singleton something very evident pops up : Singleton is implementation driven, it’s practicable (while some would argue that it’s overly used incorrectly [which I agree to, but we'll leave that for a later post, maybe]), its a technical way to write you code, it’s a tactical solution. While MVC (and others) are different, they are CONCEPTS, they are a way to think of information driven SYSTEM, it’s a strategical solution. But what MonoRail and Microsoft are doing is to endorse MVC as a framework, rather than system’s architecture solution, and in my mind this falls short. If your development group is well disciplined and the design is good, you don’t really need a framework to uphold the rules - there are many other ways to address that. What is missing in my mind (and I’ll try to prove it with a real-time example) are system architecture solutions that address real-life application development & deployment cycles that address mid to large size projects with MVC. Instead we get some development frameworks suitable to a small group of developers working on smaller scale projects, at time it seems more of a university type of solution than issues we tackle in real life.
So after all that, let’s get to the problem at hand. JAJAH is a medium to large size software project with a wide variety of technologies, we’re also a global company with Marketing in the US and R&D, Operations and other departments in Israel. One of our hurdles is that content changes should be close to the Marketing team, while today every request has to flow to the R&D team and be part of the release cycle. This causes extra work (tidious, not-so-interesting work for our killer developers) on the R&D team, and does not provide quick enough response to the Marketing team. Hence we need some Content Management System where we can have a not-so-expensive HTML guy next to the marketing team making content changes. This is practically MVC. However, we need different release cycles, the View should be developed and deployed in a different way than the rest of the system. It’s not just separating everything to different projects, DLLs etc - it’s a whole different system. We need to QA the content, having it in a staging environment and have proper roll-out procedures. We also want to limit the changes that the HTML guy can make in the system, we don’t want to give the guy full control over all rendering aspects, just certain parts. We used to play around with Offermatica (recently acquired by Omniture), but while it’s a really cool tool, it’s mostly focused around A/B tests and is not suitable as a heavy duty content management system.
MVC is cool, and it makes a lot of sense, but what we actually want is M-V-C, totally separating the components for that a framework is not enough. For that MonoRails is just not good enough since it keep everything together. What we need is some type of a Content Management System, coupled with a release cycle & deployment management, and same applies to the Model. The controller is a different story, at times we would like to couple it to the Model and times to the View release cycle.
My point in all this is that Design Patterns should not be regarded as framework solutions pre-say, but rather as design concepts being applied to the high level system architecture and not necessarily at the development level.
Amichay