Those of you following blogs and tweets in the Joomlasphere and reading about Nooku, might have read and learned about MVC and HMVC already. If not, here is a short explanation on MVC, and why you should care about design patterns and MVC in particular, especially if you’re a Joomla user.
Design patterns are reusable solutions
First of all, MVC is an architectural design pattern. Yeah, that’s a mouthful. What is a design pattern? Well think of it like this: Patterns are stuff that repeats itself, right? So a design pattern is a design that repeats itself, or you could say “is reused”. A design can in development terms be thought of as a solution, so when you hear the words “design pattern”, you can think reusable solution.
Reusable solutions are smart ways of solving similar problems without reinventing the wheel. An architectural design pattern like MVC is in other words a reusable solution to an architectural problem. Many computer softwares aren’t that different architecturally, so MVC is a solution that can be used in many circumstances.
By giving names to these design patterns, for instance MVC, developers can easily communicate between one another how they are approaching or solving issues in their applications. For instance, if a PHP class in my code is called ArticleController (where “Controller” is the C in MVC), another developer that reads this code will immediately understand what the responsibility of this class is and what it should be able to do, because he understands the responsibility of the Controller in the MVC pattern.
…like the wheel
Speaking of not reinventing the wheel; the wheel itself could be seen as a design pattern:
We use the wheel in for instance cars, bicycles, buses and trains. So the wheel has indeed become a reusable solution to one common challenge: Making a vehicle easy to move. The wheels themselves are different on each vehicle because they are adapted to suit special circumstances, but the wheel concept itself is the same: Once the solution has been identified, it’s just a matter of putting it to good use.
So if you and I are building a vehicle that’s going to solve the challenge of transporting us from A to B, and I suggest that “we should put wheels on this thing”, then you’ll basically know what I’m thinking and we’ll also have a common understanding of how we’re going to build it. If we were to travel on a snow covered surface though, you could have suggested that we used a pair of skis as our solution, instead of the wheels. I would of course have slapped my forehead and agreed with you, without needing to see complicated blueprints or having long committee meetings.
That’s the advantage of having design patterns!
Jeff Atwood also has another nice MVC analogy in a blog post of his, see the link in the references & footnotes at the bottom.
The building blocks of MVC
The MVC pattern splits your code into three parts, often referred to as a triad: The Model, View and Controller. Here is a brief outline of what job each part does, particularly in the Joomla and Nooku Frameworks.
Note: This will teach you how to talk the talk, but not walk the walk! Oleg Nesterov’s presentation “Joomla Extension Kung Fu” provides some nice PHP code examples you can look at though to see MVC in action. See the link in the references & footnotes at the bottom of this article. I’d also recommend looking into the Nooku Framework sourcecode to see how MVC is implemented in PHP there.
Here are the basics though:
The controller is in charge, as the name would suggest. When you do a request, like for instance in a Joomla site entering example.com/index.php?option=com_content&view=article&id=13 in your browser, the controller in the content component takes care of getting the request data. For this request, we have the variables option, view and id visible in the URL. From that, the controller will set the model state so that the model, which is fetching the data for us later on, will know that it needs to fetch article number 13. The controller will then tell the article view to render itself.
The view decides what ends up on the screen. It will use the model to fetch the data it needs, load the template and display the content inside that template. In this case, the view requested is “article”, singular. In Nooku Framework, the view will automatically deduct from this that it needs to fetch a single item instead of a collection of items, as “articles” (plural) would have suggested. This is a small part of the “magic” happening underneath the hood in Nooku, which makes it so easy to work with.
The model handles the data. If you need something added, edited, deleted or fetched to or from the database, the model is the class that will do the heavy lifting. The controller will set it’s states (like filtering, ordering etc), and then the model will do whatever it is told to do.
Benefits and advantages of MVC, for all of us
Why should you care about MVC and demand that your developers do the same?
A clear separation of the code
First of all, MVC splits your code into three distinct parts, each of which have clear responsibilities and limitations. When you’ve used this pattern for a while, deciding where to put a piece of code or look for a piece of code becomes intuitive and straight forward. This makes many parts of development a lot easier, because the design pattern dictates where the code should be located and what the code should do.
It also makes it easier for other developers who know MVC to read and understand the code you have written, and after that, also extend or contribute to it, or even replace parts of it.
At the heart of MVC there is the desire to separate the presentation of data from the manipulation of data, partially because we want to reuse as much code as possible, but also because we want to be able to present one set of data in multiple ways. In the Joomla CMS for instance (version 1.5 and up), you have templates, and you can change templates to easily get a list of articles to look completely different without modifying the Joomla core code. Each template has the power to implement it’s own overrides for any view in any component in Joomla. Consequently, anyone can use their own template to make a component look exactly like they want to, given that the component in question follows the MVC design pattern of course.
A new presentation of content need not only mean a new HTML template though: A list of articles can very well be displayed in a completely different format, like CSV, RSS, PDF or JSON. This can allow us to easily be able to reuse it in other parts of your website or even on other websites. So while the presentation or format of the data is different, the functionality used to fetch the data from the database is exactly the same every time.
On the opposite side: If I suddenly decide I want to store my articles in flat files instead of in a database, I can just modify the part of MVC that stores and fetches data, and leave the presentation part alone. The presentation of the data is in other words decoupled from the part of the application that communicates with the storage of the data.
My personal experience is that when working in teams, the separation of responsibilities in MVC makes it easy to divide the workload between team members. If a task on my task list just says “Article model”, then these two words also describe pretty well what it is that I need to do.
Where to go from here?
So how do I find out if my favourite component X follows the MVC pattern or not? Easy in most systems! In Joomla you can open the component’s folders, either administrator/components/com_x/ or components/com_x/ in a file browser or FTP client, and look for folders named “models” and “views”. If you find none, then the component is likely not using MVC the Joomla way.
If so, make sure to send the component’s developer an e-mail with a link to this article ;)
Design patterns are like wheels: They make things roll smoothly!
The benefits of the MVC design pattern: It provides a logical and predictable architecture to work with and collaborate on, it allows us to reuse larger parts of our code, and it allows us to modify parts of our code while other parts can remain untouched. Less code equals less maintenance, and more decoupling of code gives better flexibility and extensibility.
More importantly: MVC is the Joomla standard, so if you’re building extensions for Joomla you should use MVC like the rest of us.
References & further reading
- GUI Architectures, by Martin Fowler
- Joomla Extension Kung Fu, presentation by Oleg Nesterov given at J and Beyond 2010
- Design patterns illustrated, presentation by Herman Peeren given at J and Beyond 2010
- Understanding Model-View-Controller, by Jeff Atwood
- The M in MVC: Why Models are Misunderstood and Unappreciated, by PĂˇdraic Brady
- Benefits of the MVC design pattern, by the IBM Corporation
- Wikipedia article on MVC, which clearly states that MVC was coined by a Norwegian guy, so you’re obviously in good hands here! :)
- Patterns for beginners, by Falk Bruegmann