jump to navigation

A Sample MVC App Build on Top of Symfony2 and Laravel4 Components (Part-2 Introspection of the Skeleton) June 22, 2014

Posted by Tournas Dimitrios in PHP, sample-MVC.

Word Cloud SymfonyWelcome back to the second part of the article series “A Sample MVC App Build on Top of Symfony2 and Laravel4 Components”. Every project start with a skeleton, it’s the application’s folder and file structure (a blueprint so to speak). Unfortunately, there are no standards in this regard. While some frameworks (Symfony , Zend-Framework, Laravel) utilizes a skeleton according their own philosophy other frameworks (in particular micro-frameworks) are giving the developer the freedom to structure a skeleton according their own needs. The key point here is that the structure of the skeleton must be planned in such a way that any developer that might get involved into the project will get familiar instantly.

A long time ago🙂, before PHP released its 5.3 version (at december 2010) we were forced to follow a particular folder structure. Certainly the following motif is familiar to you : class Zend_Application_Module_Autoloader extends Zend_Loader_Autoloader_Resource We had to follow a corresponding folder structure so that the autoloader could do its job, at some extent the same motif is also followed today but we are not forced to do so. PHP Namespaces, which were initially applied as a solution for bypassing naming conflicts between different libraries that could exist in the same project, had also impact how a skeleton could be structured. Due to Composer (a PHP dependency manager), we can now customize its autoloader in a much more flexible way.

The following picture shows the skeleton used by this app : skeleton_of_sampleMVC   A quick overview of each folder :

    • Cache : When a controller needs to generate the response object, it hands the work off to the templating engine (Twig in our case) . Twig allows us to separate the business logic (stuff like : db tasks, and other dynamically defined functionality) from presentation logic (HTML code). Twig comes with a long list of predefined tags and filters that help the developer designates the “where and how” the data should be rendered. The Controller is only responsible to generate the data (the “what” to render). The whole point is that the template system is meant to express presentation, not program logic. The actual job of every template engine is to parse a template and compile it into a native PHP class. As there is no need to repeat the whole process on each request made by a browser, each template is compiled only once (on the first request). Every subsequent request will receive the already compiled file [Class]. The Cache folder is where all compiled classes are stored .
    • config : All configurations for the application (Db-credentials, routing) are written in Yaml. For better maintainability / accessibility related configurations are written into separate files (we could have used one single file for all configurations though) .
    • Db_schema : Contains the SQL schema used by this project .
    • notes : The developer can write down his/her notes. I usually exclude the content of this folder to be committed to Github.
    • vendor : This folder is automatically generated by Composer, all libraries (which are defined in composer.json file) are downloaded into this folder. We don’t touch the content of this folder for any reason .
    • web (public_root) : This is the only publicly accessible folder, all client-related resources (images , style-sheets and JavaScript) are stored into this folder. The index.php file is the front-door of the application, it’s an implementation of the Front-Controller. Based on the URI , the corresponding Controller is called (in technical jargon it’s named “dispatched”). Not all incoming requests should touch the Front-Controller though, for instance, a request for an image, Js or CSS file should not be handled by the Front-Controller, it’s the responsibility of the server to deliver those files. The Apache server has a really sophisticated rewrite module which provides a powerful way to do URL manipulations. We could liken this module as a traffic policeman, it directs all requests to index.php, except when a matching file is found under the public_root folder. Appache’s rewrite module is highly configurable, usually rewrite_rules are written into a “.htaccess” file (on shared hosts) or directly into Appache’s configuration file (into VirtualHost directive sections). How to write rewrite_rules is out of the scope of this article, my Centos box has the following configurations for this sample MVC app :
# cat /etc/httpd/conf.d/local.samplemvc.conf
#NameVirtualHost *:80

    DocumentRoot "/home/username/web/sample-MVC-with-Symfony2-components/web/"
    ServerName local.samplemvc
    ServerAlias local.samplemvc
    ErrorLog /var/log/httpd/local.samplemvc.error_log
    CustomLog /var/log/httpd/local.samplemvc.access_log combined
    ServerAdmin admin@myhost
    <directory "/home/username/web/symfony/sample-MVC-with-Symfony2-components/web/">
DirectoryIndex index.php
         Options All +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all

  • src : This folder contains the logic of our application (Controllers, Models , Views and Custom Classes). Actually this is the place where we will spend our energy. Controllers have methods, each method is a task the Controller is capable to fulfill. For better manageability, tasks are grouped into separate Controllers, ie authentication related tasks go into an AuthController , user related tasks (CRUD operations) go into an UserController. Each task (Controller-method) is related with a template that exists in a directory with the name of the Controller ( for instance, UserController::listAction is related with /views/user/list.html.twig). That’s a standard implemented by all frameworks nowadays (a naming convention so to speak), it can be overwritten though (we will get to this on the next part of this article series) .

Let’s recap the workflow of our application :

  1. A request comes into our Domain (most likely from a browser) . Apache directs all requests to index.php (the FrontController), except when a matching file is found under the public_root folder (images, JS or CSS files) . 
  2. FrontController’s responsibility is to call the corresponding Controller::action (based on the URI of the request)
  3. The Controller::action will execute a specific task (most likely, by off-loading tasks to Models and Services Classes) . The result of the task, a collection of data, will be passed over to the template where it will be rendered and returned to the browser.

Final thoughts (of this second part) :

No matter the size (or complexity) of an application, organizing its folders and files will pay off down the road (in terms of maintainability and teamwork).  As there are no standards of how to structure a skeleton, just use your sense. The key point here is that the structure of the skeleton must be planned in such a way that any developer that might get involved into the project will get familiar instantly. On the next part of this article series, we will dig into the actual code. Thanks for reading …….

Links : 



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s