Posted on March 22, 2010
I would put money on most programmers these days having at least heard of the architectural pattern “MVC” (Model View Controller) and I expect many have used it or been involved in projects which claim to implement said pattern.
MVC in short is a typical hierarchical pattern which allows lots and lots and LOTS of objects to be split up into a. a model: this in short is the actual object within a package which is usually used to represent a table in a database somewhere. It handles all the prep work needed to store, modify and delete an object from somewhere. B. is a view. The view itself is what the end user actually sees. The only logic in here should be things like looping through a collection of objects to display. C. (quite aptly) is a controller. This does exactly what it says on the tin and controls the object and how it is presented to the view and also does the “doing” of things that the view tells it to do.
“How very simple!” I hear you cry! “I am SO going to use that – amazing!” I hear you exclaim.
It is exactly that IF and this is a very big if, IF it is actually appropriate.
Please be reminded that this is, my most humble opinion and I would not dream of depriving you of your controllers with data calls in or your models that logs a user in for you… unless you want me to work on it in which case, buck up your ideas sunshine.
A very appropriate example I did just happen to mention there. In object oriented programming, you have to be very careful not to fall into the trap of “I use objects because I can reuse the code in them”. This I think a lot of programmers are guilty of thinking like whether they would care to admit it or not. What that is my friends, is a library. A library is a collection of reusable objects and code. Object oriented programming in itself runs much much deeper than that. In order to explain this fully, I direct you to something that I heard in my first ever lecture on Object Oriented Analysis and Design. Objects are nouns, inside the object we have properties, we set and get those properties in that object. That was it, that’s an object in very simplistic terms. As commercial programmers, we are driven by bosses bending our ears about timelines, deadlines, overdue promises (and today I was told you do this to time even though a week was wasted because you were the only one in the office without any specifications – jobs will be lost.) which in turn can make us a tad sloppy when under pressure if we haven’t had the time to really plan out our work properly. This can be a time where you find action work creeping into our lovely defined objects which should really be abstracted away as perhaps a helper object or a service object.
Due to the sheer size of some MVC projects, we can have exactly that. A lot of rushed projects in one big MVC structure with lots and lots of hacky implementations of something that resembles MVC. This to me, is a reason to reconsider your architecture…..
Although I’m not biased towards SOA, I do really appreciate the freedom of design for a system that it provides. For example, in your standard e-commerce app you would have:
3rd Party integration (suppliers and whatnot)
The list expands and contracts depending on requirements obviously but we can safely assume that a lot of those things will be in even a small e-commerce project.
Now say for example that a user has lots of properties, the project also has lots of different types of user. You need to establish what user is what and use the properties accordingly throughout the system. You also have a mobile app that needs to use the same code without all the web based gubbings. In a normal MVC structure – you would use the same bootstrap file to access the whole project and change your views.
OR, just an idea: You could have a component, loosely coupled to other components with a lovely interface that you could just go “Dude, I need the properties for that user” or “Righto chaps, time to change this user’s email address.” Or something overly complex like “Ok mate, I need a full list of users’ email addresses and permissions to do this manic thing with emails” Ok that wasn’t that complicated, I apologise. However, The last example is a good one: I do not want to have to go into my massive huge application to get a list of user email addresses. Neither do I want to have a big application that I have to rewrite loads of stuff so I DON’T have to do that. By having my user management componenent I can do exactly “Ok mate, need a list of stuffs – gimme” (this is how code should be hehe) also since everything goes through my interface, my code is protected from hacky developers going “need this thing, going to go into the model and just do my action – simples”…. Don’t do that George, it’s not nice.
The benefits of having loosely coupled components other than the ones I’ve mentioned include the difference in actual code usage and implementation risk levels.
By having a component that represents a service or application, you are abstracting your code for this project away from the major enormous project as a whole, this means that your api implementation is lower risk as you only have to worry about the conversation between apis rather than lots and lots of reverse engineering to find those params you got the wrong way round during injection…
A lot of people might say – but dude, I may want to use that XML converter object in another component! Yes you might, that’s why I’m also a huge advocate of libraries… Whack it in there. Or even better, use something like Zend Framework (minus the MVC stuff) and just use that. In a lot of places, I’ve had a core library for stuff that is needed in multiple components and Zend Framework library for stuff that I really don’t want to write again – I’m pretty sure those people had much more time to write that and it’ll be a much better implementation of it since I’m so stressed writing projects in time for silly bosses……
MVC was ditched by Java for a reason: I hope this helps to begin to explain why!