A Sample MVC App Build on Top of Symfony2 and Laravel4 Components (Part-2 Introspection of the Skeleton) June 22, 2014Posted by Tournas Dimitrios in PHP, sample-MVC.
add a comment
Welcome 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.
A Sample MVC App Build on Top of Symfony2 and Laravel4 Components (Part-1 Introduction) June 20, 2014Posted by Tournas Dimitrios in sample-MVC.
add a comment
The Model-View-Controller pattern (MVC) is a methodology for separating the concerns of an application’s domain, presentation, and user input into separate (specialized) components. The days where HTML code was intermixed with server-side code to achieve dynamic web-applications are just ancient history (in terms of Internet technology). PHP itself works like a template engine. However, when used irresponsibly, it leads to very ugly and un-maintainable code (not to mention the environment for teamwork). Within the context of web- development environments, MVC is the de facto architectural design pattern, not the only though .
Many PHP frameworks nowadays provide an “out of the box MVC skeleton” as starting point, a developer has to make a careful plan before he/she decide which framework to choose for the intended project .
This article will present a fully functional MVC application build from components taken from two well known PHP frameworks (ie Symfony2 and Laravel4). The final result is a simple “User list” where users can be registered / updated and deleted from the database (basic CRUD operations) . Not a very useful practical example, one might say. Yes indeed, this simple example might not have a practical implementation. But it’s the best way (IMO) to demonstrate the core concepts of a well structured web application. All frameworks are doing the exact same things to achieve similar functionality, in a more efficient way of course. A lot of Bootstrapping is done behind the scenes until a framework’ skeleton application is ready to respond on requests made by a browser. Just for indicative purposes, Symfony2 / Zend Framework2 are instantiating more than 200 Classes at bootstrap. Many more classes are lazy loaded “just the time” their functionality is required by using Dependency Injection. Even more, all instantiated Classes are kept as services in a container (a bucket so to speak) for later use (might the application demand their services). The practical example of this article intentionally refrained to use a Dependency Injection Container (DI). Firstly, for simple web applications (as this one) there is no benefit to make use of it. Secondly, the reader will get a better overview how the puzzle is structured, as everything is on front and nothing is passed over to background functionality (which is the case if we had to use a DI container). An obvious question that might arise is if this code could be used on production. Although my answer is definitely Yes, I will conclude with : “just because we can doesn’t mean we should“. There are so many frameworks to choose from, this fact makes this code-base not the best choice for a production application that might be extended with extra functionality in the future .
This Blog has already started to publish an article series about Silex. That framework (Silex) can be used as a foundation for all kind of web applications (from prototyping and small web apps up to high demanding web services and API’s) . Of course there are so many alternate solutions out there which could be an excellent choice for our next web application.