Shall we use a MVC framework..

As mentioned in the previous blog, we’re currently deciding how our new project should flow. By this I mean, do we use the more conventional methods we’re used to (hard coding our php for each individual page) or to take the plunge and go the Model View Controller (MVC) route.

I’d decided a few days ago to look into MVC, although i’d touched on this within Ruby on Rails, i’d never done it within PHP. After some initial research, it seemed that this wasnt as complex and as far fetched as I initially though – therefore worth a look in my opinion. With help from online tutorials and people in the know of MVC frameworks, i worked through and created a simplistic framework that worked with the “Smarty” templating system, which was also then tied in with PEAR::DB for database abstraction.

I created a few simple functions, simply passing data throughout our framework to display customer details, and then change this depending on search critera. Not exactly complex, because this is easy to do with in PHP anyway, but the thing that struck me was, suddenly im not repeating code, and things are beginning to look more logical; in the way that I know exactly where I have to go to edit files, I know exactly what page does what, and the whole process seems to flow in controlled manner. This seemed a plus point for me, and I thought we may be onto a winning idea.

A brief meeting was then held between myself and Adrian who talked over this aproach; we also consulted Dave (briefly), Jake and Gregg and Senokian for the expertise in MVC Frameworks.

Their opinions were mixed, there were plus points and downsides to the idea we had, the main downside thats stuck in both our heads is the learning curve it may cause to fully understand how this MVC will work, and how we can train someone else if they needed to.

The opinions of Jake and Gregg at Senokian basically stated that it may not be a good idea for us to go down the MVC aproach due to the learning curve that would be needed by myself in order to get upto standard, but if we did decide to go down that route, and i felt comfortable in aiming towards using MVC then there are numerous frameworks we coulc use, such as smarty.php.net.. This basically allows us to create the design quicker, and perform template swaps/alterations all in one place.

This has brought some confusion between us, because Gregg and Jake have a lot more experience with MVC frameworks than me, so I have to take their advice, and have to admit im really in two minds now

My opinion now is to spend a few days trying to work with this framework, and come up with some useful functionality. If i fall into problems then we may need to give the MVC approach a miss, but if things work how we expect them, this may be an area we need to solidly look into.

  • Tony

    Hi Rich,

    I’m going to step through the different parts you mention and try to explain the pros and cons of each approach.

    1) Smarty
    The external chaps are right when it comes to Smarty – or indeed any templating framework you wish to use. Lots of techniques can be simplified with this layer of abstraction. See this link ( http://www.hashphp.co.uk/examples/form.tpl) for an example Smarty form that has the following benefits: a) After posting, if there were errors saving, the form fields are automatically repopulated. b) all values are sent through htmlentities() easily, c) control logic is there to show error messages etc. All you need to do in your code is assign the $errors and $error_message vars to Smarty.

    2) PEAR::DB abstraction
    This is one of those techniques that has a very shallow learning curve. It almost exactly the same as working with the native pgsql function calls, but with added benefits. Some examples to show what I mean.
    $count = $res->getOne(“select count(*) from users”); // That’s all the work you need to get a single value back from the object.
    if (PEAR::isError($db)) {
    $gui->assign(‘db_error’, $db->getMessage());
    $gui->display(‘db_error.tpl’);
    }
    The above example, when you’re working with smarty allows you to continue showing a page, but show an error template in the same style as your site – you can even use the same header/footer smarty templates.

    The benefits for this are additional simplicity in the code, not added complexity.

    Both PEAR::DB and Smarty have comprehensive examples available online, and are well supported in the industry. I would find it hard to believe, after seeing some examples, that a php developer would have to struggle much learning those concepts.

    You mention a complex form that might require Ajax-style features to auto-save the details without the user having to submit the form manually. Let’s recap on the MVC pattern and see roughly how it works…

    With the form example..
    1) Browser sends get/post data to your main controller script.
    2) Main controller creates all your objects and first calls the model controller.
    3) Model controller looks at get/post data and makes logic decisions (insert/update the database, sets some output data and sends it back to main controller
    4) Main controller sends model’s output as the view’s input
    5) View controller takes input and makes a decision on which template to display, and which data to give it.

    With your form, if you were to submit it with ajax, imagine that your Ajax feature also pops &method=ajax on the end of the request url. Your view controller can be configured to just ignore those requests. That’s it. The whole added feature to handle Ajax posts is just one line:
    if ($request[‘method’] == “ajax”) { return; }
    You don’t have to change anything in the model, or even the index (main controller).
    That’s for a simple ajex post. You might want to extend it to handle errors as well. In which case, you’d change the view controller to use another template file instead of just returning empty. Perhaps one with a JSON structure, or maybe XML.

    The thing to know with the MVC design pattern is that it doesn’t matter what you’re developing, this is just a way to structure your code. If you’ve grasped the principles of the MVC skeleton that you’ve been playing with, then that’s it. Your learning curve has finished.

    Any developer that will replace you will have to learn whatever method you structure your code. The benefit of using a well-proven design pattern is that absolutely anyone who understands MVC will understand how your code is structured. I don’t believe it would take a steeper learning curve to understand how to *read* this code, than any other custom pattern you would write. Admittedly, this is a harder pattern to *write in the first place*, but once it’s there, I consider it much more readable and structured than any custom method. I think this pattern creates much more maintainable code.

    Now, you ask about whether this design is an overkill. The MVC structure to the design isn’t – once it is written, it’s done. Having that skeleton in place allows you to copy it straight away to other projects, all future sites you develop can use the same template, allowing you a structured. consistent base to all your work. You can get stright on to writing your business logic and designing your templates.

    Smarty – this can be considered an overkill for some projects, but I think the memory footprint is worth it just for the lovely helper functions it offers: {html_checkboxes} and the syntax for using default values: {$foo|default:”Empty”} alone make it worthwhile for any template designer.

    PEAR::DB – not an overkill, this is an established and recommeded method for db comms. I would always prefer this to internal functions. Simply by changing the connection string (DSN) you can hotswap to another database system (assuming you write standard sql of course :-D)

    Right, that was probably a longer briefing than I expected to write there, but I hope it helps to displell some rumours and misconceptions about the techniques above.

    To put it simply – using these methods you are creating more elegant and simpler code, not adding excessive complexities.

    Tony

  • Craig

    As Tony says above, MVC frameworks are extremely handy when it comes to reading someone elses code. You don’t have to understand what the bespoke pattern it is they’ve used to code the application.

    MVC is a standardised pattern, normally created by using 2 controllers one for view and one for logic. These are managed by a single php file.

    MVC keeps all code inside little small blocks, which means if you should need to edit a particular page, then you just go and change that small code.

    Personally I believe you will experience more problems using a procedural code base than if you went with a MVC pattern based CRM system.

  • Motin

    I just performed a large investigation of MVC frameworks. The most stable and complete MVC development framework for php is Cake PHP, http://www.cakephp.org/ which in many ways outperform even Ruby on Rails, without having to move away from PHP.

    To me it seems MVC is certainly the way to go for you – and for anyone not writing temporary web pages. The maintainability will payoff.

    I’d recommend starting off from an example website/application constructed using CakePHP and build from there.

    If your needs are more refined, do not forget that there are thousands of open source projects that you can use as a base of your projects. For websites, using a CMS like Joomla is a great way to start off for example.

    Keep posting updates on your progress and do not hesitate to openly ask questions again. I’ll try to help you as good as I can.

    Cheers!

  • Thank you guys, comments and input gratefully received and taken on board.

    adrian