To MVC or not to MVC….

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS
  • Reddit

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:

Display

User Management

Product Management

Stock Management

Warehouse integration

3rd Party integration (suppliers and whatnot)

Order Management

Payment Gateways

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!

2 Comments on “To MVC or not to MVC….

  1. To date I’ve been mostly uses classes for organisation, e.g. Setting.php contains everything relating to settings, include getSetting, saveSetting, getAllSettings and so on. I started looking at models – but haven’t incorporated them into any of my own projects yet.

    In another post you mentioned singletons. I use these to save time so I don’t have to continually instantiate a class, let’s say a database driver. myController:getDb()->query(“select * from tablename”) is how I do it. What’s your view on the use of singletons for regular classes? I guess I could just do className::staticMethodName … but with a database driver, sometimes I’m working with multiple databases, so I need to know which one I’m connected to. Would you use a couple of objects and a singleton for each, or would you disconnect/reconnect whenever you needed to switch databases? A good example of where I need to do this is using a plugin to load data from another database.

    Also, how do you feel about static methods vs. non-static methods?

    I’d like to learn more about why you think MVC isn’t a great concept; I didn’t completely get it from your post, but I do see some of your points.

  2. Thanks for your comments Ben!

    I think it’s really important to use patterns where they actually implement the advantage they were made for. Singletons are really useful in languages like Java where you have multiple threads and you can use the same object over these. As PHP is single threaded I think you can use something like a Factory to return instances of objects such as DB objects etc but because it’s on one single thread – you actually don’t need to use a singleton at all as once that process stack is finished – all objects instantiated are usually destroyed. Also since PHP5 changed the way objects by reference rather than straight copy, which is why PHP4 used them a lot, we have less need for them now than ever.

    For multiple DBs, I would store the db object in a registry and instatiate them as I need them using namespaces most likely. Zend_Registry is pretty good for this as it happens and this technique is used a lot funilly enough in most Zend MVC projects.

    I think in big systems that PHP is being used for these days is much more suited to component based development such as SOA and in some respects sometimes RMI. MVC is a nightmare for 3rd party integration and having components would make it so much easier. It also means that you can use a more appropriate pattern for different aspects of your system rather than MVC. For example, I’ve built an identification system in the past for mobile subscriptions that MVC would’ve been a nightmare for and it suited Chain of Responsibility best. If the system I was building it within was MVC, the solution would not have been either as elegant or simple. Simplicity is key and I think MVC gets far too complex as systems get bigger and therefore – botched up quite a bit.

    This is also I think where MVC can be rather fuzzy at whether it’s an architecture pattern for systems or a design pattern for more focal. I would quite likely use MVC for a display component as it really works well for that which means the models only represent what the display component needs rather than users, stock etc where you would interface with the other components in controllers and helpers.

    Static methods I think are great if you want multiple instances of something, i.e users and make a collection of objects. I would usually have static methods in things like helper classes where the action of the method returns my collection of objects or if I’ve already given it the object to work with. Most classes that are not objects per se in themselves but perhaps facilitate the instantiation/modification etc of objects are most suited to the use of static methods.

    That’s what I think anyway!

Leave a Reply

Your email address will not be published. Required fields are marked *

Email
Print
WP Socializer Aakash Web