In the same way that you wrote your framework with PHP, other people did it too. It did not take long for people to realize that entire frameworks were reusable too. Of course, one man's meat is another man's poison, and as with 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 Laravel is also there, providing a lightweight and fast framework for those who need fewer features. Due to the nature of this book, we will focus on the latest ones, Silex and Laravel, as they are quick enough to learn in a chapter—or at least their basics are.
In this chapter, you will learn about:
- The importance of frameworks
- Other features of frameworks
- Working with Laravel
- Writing applications with Silex
In Chapter 6, Adapting to MVC, we barely introduced the idea of frameworks using the MVC design pattern. In fact, we did not explain what a framework is; we just developed a very simple one. If you are looking for a definition, here it is: a framework is the structure that you choose to build your program on. Let's discuss this in more detail.
When you write an application, you need to add your models, views, and controllers if you use the MVC design pattern, which we really encourage you to do. These three elements, together with the JavaScript and CSS files that complete your views, are the ones that differentiate your application from others. There is no way you can skip on writing them.
On the other hand, there is a set of classes that, even though you need them for the correct functioning of your application, they are common to all other applications, or at least, they are very similar. Examples of these classes are the ones we have in the src/Core directory, such as the router, the configuration reader, and so on.
The purpose of frameworks is clear and necessary: they add some structure to your application and connect the different elements of it. In our example, it helped us route the HTTP requests to the correct controller, connect to the database, and generate dynamic HTML as the response. However, the idea that has to strive is the reusability of frameworks. If you had to write the framework each time you start an application, would that be okay?
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 again! Even though this was quite different some years ago, nowadays, all the main frameworks can be installed using Composer. We will show you how to in a bit.
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 you 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 yours so that you 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.