If you consider developing a framework you should begin with the logic of framework design. This article will show you the concepts of framework building. We will be discussing framework logic with MVC pattern in mind.
First we have to understand what the framework should do. Frameworks help developers minimizing repetitive code that is easily manageable and reusable. If we break up a PHP web application (generally websites) we find that some areas of the code could be isolated from the rest of the logic and reused in other projects as well. We like to call these codes modules.
Now we have to understand the code flow. What happens when a user visits our website, makes a request. For example if a user requests to see the ‘work’ section on our website (www.primalskill.com/en/work) the application figures out what section of the website is required, gets the data from a database, formatting it so it will be nice and sends it to the user.
By figuring out which section is requested is generally done looking at the URL. In the example above you can see in the URL there is the word ‘work’. This means the user wants to see the websites ‘work’ page. In framework thinking this could be a module. But that’s a little bit more complicated.
In a module based framework a request looks something like this:
The front controllers job is to load the general classes, the master configuration files and based on the request figure out which module to load.
The module job is to get the requested data from a database, file, etc. format the data and send it back to the user.
In the front controller layer we can implement security and URL routing filter classes. We can load a database abstraction class and pass it to the module.
It’s a good practice to keep your files strictly organized in folders with access rights and so on. I will present here a general project folder structure:
Here you can see the general structure of a project. The ‘root – libraries’ folder holds all the common classes that a modules may use, like database abstraction class, error handler class, etc. The ‘master’ folder contains a main front controller. This file loads general modules, master configuration and resolves which module to load. Each module has separate controllers, models, views and configuration specific to that module.
It’s a best practice to turn the error reporting off when you put the application online, but also know when an error is occured, that’s why is a good advice to make a logs folder and put the exception handler generated files in here.
Of course there are lot’s and lot’s of other file structuring frameworks, this is just one of that many. I hope you enjoyed reading this article and check back soon for new ones.
Hey, I saw that the first part of this post (Basics of framework design) got a little bit attention I decided to continue that thought. Before you continue reading make sure you read the first part for easier understanding of this post.
In order to use or even build a framework first we need to understand what type of architecture the framework was built upon. We need to understand the design behind it.
So let’s start with framework types generally. In the PHP world the majority of framework are either full stack or glue frameworks.
A full stack framework is essentially a lots of tight coupled components/modules, not necessarily built upon each other, but almost all the time this is the case. For ex. Symfony or Cake PHP are full stack frameworks. Another characteristic of this type is that it enforces the developer to use these components in order to build the web page or web application.
A glue framework is composed by a bunch of loosely coupled components. It is rather a flexible type, you can use these components together, but not necessarily. Zend Framework is an example of glue framework.
In my personal opinion a team with less than 5 or 10 developers should use a glue framework, because it’s much easier and much faster to work with. The developers doesn’t have to learn all the ins and outs of the framework. Larger teams almost always should use full stack frameworks, because with larger teams the most important and frustrating problem is communication. Therefore a project manager who enforces a full stack framework on his team will cut down the development time. The developers will have consistent components to work with and the framework will enforce a consistent coding style and conventions making the project more manageable. (eg. On many of Yahoo’s pages a modified version of Symphony framework is used).
Many of these frameworks are based on the MVC architecture and they’re push based. MVC stands for Model – View – Controller and what essentialy means that the application is separated into model (or data access), controller (or action) and view (or user interface, template) layers. Push based means that the action (or controller) pushes the data gathered from the model (or data access) to the view (or user interface). CodeIgniter, Zend and Symfony are all push based frameworks.
