Tag vite : Tags... amplifier application bd blog book computing dailymotion debian dev electronic forum friends geek git github javascript jquery linux net nodejs ooc php pomm postgresql python screen shell silex speaker store symfony ubuntu valve vim whitepaper youtube

MVC ? Wasdat ?

I have been doing code audits for several years now and I am still amazed at the use of symfony’s MVC by some developpers. Miles long actions, sfContext singleton calls everywhere, no use of the session class … symfony is a nice framework, you can develop very complex web sites and keep them maintenable using good practices but it can’t prevent people from building what I call a «heap of code».

When you are working with a heap of code, fixing a bug somewhere is probably creating a new issue somewhere else … or not. It lacks decoupling. Imagine you want to install electricity in you brand new home and the electrician tells you you must paint everything in red to install power saving lights, this is a decoupling problem. When it comes to web development, there are 3 essential roles in a web site:

• the developer (the geek)
• the designer (the artist)

• the customer (the businessman)

The developper knows about computing systems. The french word for this guy is «informaticien» (informationist): he knows how to store and retreive information from computing systems (hard drives, databases, protocoles and so on) sort, filter and put data in the form he wants.

The designer knows about presenting the data, the user interface is a really important part of the web applications today, he is the man making your users life easy with your application.

The customer knows nothing about Vim nor Gimp, he knows his business. He knows processes involved in his job and the order of the different actions composing them.

Decoupling these guys work means changing the aspect of the site does not change the business processes. It also means you can migrate from MySQL to PostgreSQL without changing the design. Theses 3 different and decoupled layers are called MVC !

MVC stands for Model, View, Controller I know it looks quite technical but don’t worry, as usual, symfony makes our life easier.

The businessman is the Controller. People come and send him queries he has to reply if he can. Imagin he works in an old (or french actual) administrative office. People come with tons of certificates to the counter and ask this guy the “very important A38 authorization”, the “green card” or the famous “Certificate of stupidity”. He first get from his customers the information he needs to process their queries and then he calls … a geek ! The geek knows how to retreive data from the files, cabinets and archives. Once the data are up to date and he has the information he needs, the businessman must send a reply to its customers. He gives everything to the artist who draws it and then he can give the result back to his client.

The businessman is sort of a conductor : he does not play any instruments but he decides who plays what, when and how.

The controllers : the actions

In symfony 1.x, controllers are called actions. If we refer to the previous paragraph we agree nothing happens directly in the actions. The global workflow takes place here but processes are coded elsewhere as class methods. This means actions are thin. One line = one business action :

if ($form->isValid())
{
    $this->getUser()->loginWithUser(PgLookGetMapFor('SpUser')->findByLogin($form->getLogin()));

    if ($request->isXmlHttpRequest())
    {
        return $this->renderPartial('reply', array('name' => $this->getUser()->getUser()->getName()));
    }
    $this->redirect('@another_place');
}

$this->setTemplate('show_login_form');

In this simple example, we can see the controller doing nothing. It is just taking decisions about what to be done and what to do (or not) when errors occure. This is NOT the place for technical stuff, SQL queries, XML handling, have to be in classes. There are no reasons ever to find a Propel Criteria, a Doctrine Query or a PgLookWhere instance in an action, theses are geeks toys.

The geek : the model

Model is composed of classes that represent business oriented objects. They are a layer between the physical implementation and the business representation. In the previous action, the controller does not care if a SpUser is stored on a ancient scroll brung by carrier pigeon or stored in a loosy database system. This is the geek’s job to ask the computers with modern softwares to trigger all the mechanisms needed in order to retreive, update, filter, sort in a consistant manner the information the controller asked for.

«Smart data structures and dumb code works a lot better than the other way around.» (Eric Raymond) This is the geek’s job to create smart data structures allowing dumb code to take place in the actions.

In symfony, all the model classes are somewhere in the project’s lib directory depending on the ORM you use (or not). Here you see, the session is also part of the model but is probably tied to your applications instead of your whole project. Most of your project’s code will take place in the model layer.

The artist : the view

The view is not only (x)HTML with CSSs but can be XML, PDF or plain text. In fact one of the most difficult part of this layer is to find out how to split your templates in efficient and re-usable partials and components. This is especially true if you are using Ajax.

As you are viewing my site, you probably already know I am far from being an expert of this layer I will end my article here.