Xerox PARC gave us a wonderfully useful way to think of how to structure software called estoerically enough Model 2. Most people know this as the acronym MVC, this stands for Model View Controller. MVC is likely the most frustratingly useless acronym ever as not only does it tell you very little about what Model 2 is what it does tell you is wrong. A more accurate acronym would be MCV or VCM.
The premise behind Model 2 is pretty straightforward, it’s significantly less complex than people make it out to be. The first thing you have to remember is what software really is. Software is a tool we use to interact with a “system”, that system can be entirely encapsulated within the software or that software can exist within a greater system. An example would be the catalogue search terminals use software to search for books – it’s part of the system but it’s not the system in its entirety, the same is true of the software running the check-out terminals or the public access terminals. Software is a way for you interact with the system that’s different based on the tasks you wish to perform.
So the first thing is the model. All the software that allows you to interact with the library system, even things like their website share the same model. The model for each application will likely be incomplete but not contradictory. For example, the public access terminals don’t need to know about the books but they DO need to know about library memberships. The search terminals don’t need to know about library memberships but do need to know about library cards. Both of these share the same model because whatever domains they both cover are in agreement. A check-out terminals understanding of a library card is the same as a public access terminals. All these systems have the same understanding of how the system works.
Let’s narrow our focus and talk about the search terminals. The aspect of the library model search terminals are concerned with are books. Now, books have a bunch of information such as titles, isbn numbers, publishers, authors, subjects, and check-in statuses to name just a very few.
The model is the structure of the information and the information itself – this is important because if you change either one of these you have a different model. Also, 99 times out of 100 the model will be represented by a database system in software if it isn’t a database it’s something that behaves just like one.
Now, the user should not have to be placing SQL queries and interacting with the model through it’s “generalized” interface. We want something that is tailored to searching for books, right? So, we create an interface for viewing books in a fashion that makes sense for books. We have them sorted by title, we even have little pictures showing up next to them of the book covers. ISBN numbers are listed after the titles and we’re even presented with the status of the book and an option to put a hold on it.
What I just described is the VIEW, it’s our little portal – our HUD to the model. The is the template into which we inject our specific information. The search results for “Moby Dick” look very similar in layout to the search results for “Information Theory”, the difference is in the content. All those things that look the same from search to search are part of the view, the content itself is the model.
Wait, didn’t we miss a step? What about the controller? The controller converts the structure of the model into the layout of the view. It’s the middle man that organizes and presents things in a way defined in the view, it also does the reverse. Searching for something? Well, you put in your query and the controller converts that query from something a person understands to something a computer understands, and does the reverse with the results sent back by the model.
Why is this special? Well, it’s another very useful principle in software engineering called “encapsulation” or “separation of concerns” - the two are roughly interchangeable. The idea being that the view doesn’t have to know about the model, and the model doesn’t have to sort things in any special way for the view. Say, for example, we have a search function that should run on a Palm. Well, we’d have to create a new view and define a new way for the controller to convert from the model to the view. Having a single model allows for all sorts of different software to interact with a single repository of data.
Rather than create a separate system for storing books for searching another for checking them in and another for adding new books to the collection. A library can simply create new aspects to the view and controller that interact with the single model – which is like the rosetta stone for all these systems.
The final point regarding Model 2 is that it has a V shape in terms of plurality. There is only a single model, the controller is at least as big as the amounts of elements in the model, the view on the other hand is as big as there are ways to interact with the system.
Why is this important for LiberalLab? Well, liberallab is going to have a single model made up of forum posts, users and documents. The controller will have to manage the forums, user creation, documents as well as specialized features like document-discussion parity and karma management. It’ll also manage all of our validation of inputs to make sure no one hacks our site or gives us nonsensical information. The view of course will be the method that users interact with the system. Initially we’re building it for looking at in a browser using XHTML and some RSS / Atom output as well.
It might be worthwhile, in the future, to build versions usable from mobile devices like Blackberries or to build web services (a special kind of machine-readable view). However, since we’re using Model 2, these can be built later without having to alter anything out of the device specific code.