Robots are cool

Warning: techy post alert, but if you’ve got past the title, you might just be interested. I’m just experimenting with MVC in a web environment at the moment, so please don’t take anything I’ve written here as gospel. I’ve written this mostly because it could be interesting to read it again in six months – “What was I was doing that for?”. There are several good sites to read about this stuff if you’re interested, although the nature of it means that it’s all open to interpretation and modification.

I’ve been messing around with MVC as a framework for SC3 recently. Mostly I’ve just been trying out ideas and getting a feel for how things work to see if I want to use MVC at all. Because it was the first site I had developed with any sort of database interaction, ScottishClimbs currently runs almost completely on procedural code. Recently however, I have been frustrated by looking at the spaghetti mess of code that was left over from SC2. At university I did a lot of work with Java, and have a decent understanding of object-oriented programming, so it made sense to start looking at object-oriented frameworks for the development of the new site.

I already knew a bit about developing applications with MVC and have recently done a lot of reading about converting that to web applications. MVC is a great way of separating business logic from presentation logic and data logic, and this is the aspect of MVC that I really like. However, it has some features that seem awkward for web development. In order to stick to the MVC model a lot of people are having a single controller (FrontController) and limiting access to the entire site to one page (usually index.php). The controller then takes various $_GET parameters and determines what view (page) to display. I daresay a single entry point for the app has some advantages, but for me it seems to lack flexibility and certainly complicates the code. The alternative is to simply structure the site into pages as normal (index.php, viewpost.php…) and have a controller per page (PageController).

Once I’d implemented a couple of pages though, it was apparent that the PageControllers were doing little more than running some procedural code, so I scrapped them and moved the code to the page itself, which simplified things again. I think object-oriented programming is great, but I’m not sold on the idea that we need to make everything into objects just for the sake of it.

At the moment I’m at the stage where I’ve implemented a few pages, all of which access data only, but the trickyness and ambiguity of MVC is starting to show. Plenty of ‘Where does this belong?’ type of thoughts are floating around my head. I’m not sure the situation is helped by the structure of the new SC3 site – by it’s very nature accessing the data almost always involves multiple joined tables (how should models be separated: by table? Some sort of logical grouping?) and often displaying the data involves a call to fairly nasty XHTML generation function of some sort (that I wrote last year, thankfully!).

Currently I’m using several models equating to my logical grouping of the site data, the actual page as the controller and one view per page. Some of the models, like the PostModel – used for getting, wait for it… data about posts – have an associated helper class. This class simply provides a set of functions, used by more than one view, for helping to display the data – like generating a list of areas and categories nested in a list of posts. A view builds a page by creating a template object, calling on a helper (if necessary) and setting some variables in a multi-dimesional array (currently $content, $sidepanel, $title and $heading). When the view is rendered by the page it simply displays the XHTML file associated with the template and fills in the variables. I’m really happy with the way the XHTML is isolated from the rest of the application like this and I think the template system I’m using is simple and elegant.

MVC was designed so that the presentation, data and business logic could be easily separated and it does a great job of this. However, it’s not entirely clear what should go where sometimes, and other times things just don’t make sense when fitted into MVC. The model and view certainly make quite a lot of sense to me, the controller just doesn’t fit as nicely. The major drawback for me is the added complexity – there are a lot of different classes floating about – and this is an area that I really want to see if I can improve in my MVSomething system. MVC isn’t the perfect architecture for web development but, so far, I’ve not seen anything better and I think I’ll continue to use some form of it with my development work in PHP.