It did not take long for people to realize that entire framework were reusable too. As there are many other examples in the IT world, loads of frameworks started to appear. You will never hear about most of them, but a handful of these frameworks got quite a lot of users.
As we write, there are four or five main frameworks that most PHP developers know of: Symfony and Zend framework were the main characters of this last PHP generation, but Silex and Laravel is also there, providing a lightweight and fast framework for those who need fewer features.
• The importance of frameworks
• Other features of frameworks
Reviewing Frameworks
If we are looking for a definition, here it is: a framework is the structure that we choose to build your program on. The purpose of frameworks is clear and necessary: they add some structure to our application and connect the different elements of it. Let’s discuss this in more detail.
The Purpose of Frameworks
When we write an application, we need to add your models, views, and controllers if we use the MVC design pattern, which we really encourage us to do. These three elements, together with the JavaScript and CSS files that complete our views, are the ones that differentiate your application from others. There is no way we can skip
on writing them.
On the other hand, there is a set of classes that, even though we need them for the correct functioning of our application, they are common to all other applications, or at least, they are very similar.
So, in order for a framework to be useful, it must be easy to reuse in different environments. This means that the framework has to be downloaded from a source, and it has to be easy to install. Download and install a dependency.It seems Composer is going to be useful. Even though this was quite different some years ago, nowadays, all the main frameworks can be installed using Composer.
The Main Parts of a Framework
If we open source our framework so that other developers can make use of it, we need to structure our code in a way that is intuitive. We need to reduce the learning curve as much as we can; nobody wants to spend weeks on learning how to work with a framework.
As MVC is the de facto web design pattern used in web applications, most frameworks will separate the three layers, model, view, and controller, in three different directories. Depending on the framework, they will be under a src/
directory, even though it is quite common to find the views outside of this directory, as we did with our own.
Nevertheless, most frameworks will give us enough flexibility to decide where to place each of the layers.
The rest of the classes that complete the frameworks used to be all grouped in a separate directory—for example, src/Core. It is important to separate these elements from ours so that we do not mix the code and modify a core class unintentionally, thus messing up the whole framework.
Even better, this last generation of PHP frameworks used to incorporate the core components as independent modules, which will be required via Composer. In doing so, the framework’s composer.json file will require all the different components, such as routers, configuration, database connections, loggers, template engine, and so on, and Composer will download them in the vendor/ directory, making them available with the autogenerated autoloader.
Separating the different components in different codebases has many benefits. First of all, it allows different teams of developers to work in an isolated way with the different components. Maintaining them is also easier as the code is separated enough not to affect each other.
Finally, it allows the end user to choose which components to get for his application in an attempt to customize the framework, leaving out those heavy components that are not used.
Either the framework is organized in independent modules or everything is together;
however, there are always the same common components, which are:
• The router: This is the class that, given an HTTP request, finds the correct controller, instantiates it, and executes it, returning the HTTP response.
• The request: This contains a handful of methods that allows you to access parameters, cookies, headers, and so on. This is mostly used by the router and sent to the controller.
• The configuration handler: This allows you to get the correct configuration file, read it, and use its contents to configure the rest of the components.
• The template engine: This merges HTML with content from the controller in order to render the template with the response.
• The logger: This adds entries to a log file with the errors or other messages that we consider important.
• The dependency injector: This manages all the dependencies that your classes need. Maybe the framework does not have a dependency injector, but it has something similar—that is, a service locator—which tries to help
you in a similar way.
• The way you can write and run your unit tests: Most of the time, the frameworks include PHPUnit, but there are more options in the community.