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:
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:
3.133.134.151