The PHP Project Guide (2014)

5. Frameworks

Although we won’t be discussing anything in relation to frameworks throughout this book, it’s important to touch on what frameworks are, and the obvious benefits and drawbacks to consider. A ready-built framework isn’t something that every project should necessarily use, but if you understand the benefits and drawbacks of using a framework you can apply them successfully to a project, which in turn could save you time in the future.

Technically, however, when you build a website, the code you use is your website’s framework. When we refer to a framework we refer to a ready-built framework that’s used by more than one person to create a standard. Every project needs consistency and the majority of ready-built frameworks are consistently built throughout. On the other hand, if your website code uses consistent code and you’re working within your own framework, this is absolutely fine. You’ll often find a lot of frameworks are built and released coming initially from projects. Developers may re-use their framework for each project they start on and therefore can potentially be used by others.

5.1 What’s a framework?

A framework is a ready built structure for your application. These are mainly based on the MVC pattern, which means that Models, Views and Controllers are used, helping to separate the logic of your application. Otherwise, a framework will simply provide a basis for your application to be built on top of, meaning you’ll have a ready built file structure, style of writing your code and access to helpers that save time when writing code.

Frameworks include helpers that allow you to do things quickly and easily. We’re not talking about the basics like str_to_upper functionality, we’re talking about things that would usually take a significant of time to write yourself. For example, user authentication is used on many websites and therefore is built into most frameworks. This means that instead of creating the entire functionality to sign users in, allow them to create accounts, recover their details, etc., it’s already there for you.

A framework will typically be downloaded and extracted to a working directory. There may be some configuration to get it up and running, but this will more than likely just be database configuration, depending on which framework is used. There may also be some important security setup, like generating and specifying values for security operations like salting passwords. We’ll learn more about this later on in the book.

5.2 More about MVC

MVC (Model View Controller) is a pattern that allows business logic to be separated from views, which is essentially what you output to a user. Models tend to fetch data from a database or resource and return it, where the controller will take this data, process it and decide what to do with it to make it useful to the view. Logic will go within a controller to process anything from listing topics in a forum to processing a user login request. The view will then make use of the Controller’s process and output what it needs to the user.

So, how does this benefit a programmer? For a single programmer, you have a lot more control over the structure of your code. This means you can concentrate on outputting what you need and don’t always have to worry about what goes where. You have a defined way of processing and outputting and therefore you won’t be repeating yourself.

5.3 Don’t repeat yourself!

This is abbreviated to DRY and is an important concept in any development, and is particularly suited to working with an MVC pattern. As we’ve already discussed, models allow data to be loaded and used by controllers. This makes it extremely easy to create generic functionality to retrieve data. For example, if all your tables had a primary key ‘id’, you could create a generic handler for retrieving data by just passing the table name and which information you want to retrieve. This would cut down on the amount of code you’d need to repeat to select data from different tables.

Implementing DRY design keeps your application development time to a minimum and also means maintenance is easier due to less spaghetti code.

5.4 What a framework won’t do

Let’s get this straight! A framework will not allow you to learn PHP quicker, as helpers often exist for functions you’d usually find in PHP. For example, look at the different between the two lines of code below. They both do the same thing, but one is native to PHP and one to a framework we might be working with:

1 echo str_to_upper('Don\'t shout'); // native to PHP

2 echo Str::upper('Don\'t shout'); // used by a framework

Obviously this isn’t complicated functionality, but it could be. You’re taken away from native PHP and are plunged into a world of using functionality defined by the framework you’re working with. This isn’t all bad though. If you know how to do something anyway then why not make life easier? Good frameworks are built and designed by developers who have an extremely good understanding of the language they’re writing them for, and are those who have identified things that could have been done better and faster.

Of course, you could begin to use frameworks and never stop throughout your life, but is this really feasible? You owe it to PHP to learn its native functionality!

5.5 The benefits of using a framework

As we’ve already seen, a well built framework will provide a solid base for you to build your application on. This can help give a good, clear structure, particularly with a popular framework that is well recognised. Let’s say you choose a popular framework with a wide user base. This will make it easier for someone else to jump in and start working on your application if required, which will mean that less training is required. If you find a popular framework that suits your needs, you’ll also have the ability to join a community of people all working within the same framework, which means you can potentially get help faster, and gain useful information and tips about the framework. You may also have the ability to contribute to the framework if you discover a bug, think something can be done better or you’d like to build a specific feature. Many frameworks also provide a library of add-ons which you can freely contribute to increase the framework’s functionality.

As mentioned, the majority of frameworks take advantage of MVC. MVC allows the logic of an application to be separated and is commonly put into practice for applications with a lot of developers. Let’s say you have developers that specifically work front end, writing HTML, CSS and creating some functionality that nicely outputs database stored data. Whether or not these front end developers are qualified or interested in the backend part of the application, their job is to build on the front, so with MVC, they’d have the ability to work on the views, pulling what they need from controllers that utilise models. Likewise, the backend work would be done on the models and controllers for the front end developers to make use of. Either way, if you were to have developers working on both, it still makes logical sense to keep everything separate, making it a lot easier to manage code.

5.6 The drawbacks of using a framework

Up until now, it seems that frameworks seem like a good idea to base an application on. However, there are a few problems to address if not now, into the future of your application. There are also some considerations to make when choosing the framework for your application, which can have negative effects if you don’t make quite the right decision.

Frameworks are not all the same. You’ll find that one framework will be suited better for a type of application than another. Likewise, you may find frameworks bloated with features that try and suit to everybody. Whatever your requirement, it’s extremely important to research any frameworks you may have come across and judge whether it’ll work well now and into the future. For example, your application may rely on fast execution time, so a feature packed framework may not be suitable for you. And, of course, in this situation you’ll need to gauge execution time of any helpers that the framework may use.

A common problem with the perception of frameworks is that they’re built more securely. The reality is that even the most popular framework will have security flaws. This isn’t the problem, because security flaws will always pop up. The problem is that the assumption that frameworks are always secure means that sometimes these problems get ignored. If you choose a framework with a large community, it’s more likely that any problems with the framework will be reported to the community and be fixed and released to download. It’s very important to keep the framework you’re using up to date by using newer well tested versions and patching any security flaws where patches are available.

The last consideration depends on how much work you do outside your framework. By this I mean that if you’re constantly working within your framework, you may be stopping yourself from exploring what raw PHP offers. This obviously depends on how much you’ve learned prior to using a particular framework. If you decide to use a framework, don’t let it become so normal that it overshadows PHP on its own.

It’s also worth mentioning that people often use frameworks incorrectly. That is, they write code within the framework not in the way it was originally intended to be written. I could simply download a framework, start using it but go wild, creating files in the wrong place, modifying code that isn’t meant to be modified, and using helpers incorrectly. A good example of this would be to literally set a session on the spot (perhaps for a logged in user) rather than using the helper built into the framework to handle this. There are no constraints within pure code, so it’s always a good idea to get to know the framework you’re using either through the documentation or someone who can teach you to use it properly.

5.7 So what next?

If you’re deciding which framework to use, base it around several factors. These are:

1. What your application requires and may require in the future. The more helpers that are available that will of use to you, the better. On the other hand, don’t just pick something with the most features in a panic, or you may be sacrificing performance for features you don’t need.

2. What looks easiest to learn or the most widely used. Really, this is for if you plan to employ people to work on a team. The last thing you want to do is pay for any training or waste time waiting for someone to learn a framework. Ideally, you need to be in the position to employ people that know the framework well.

3. Community support if you’re learning the framework yourself. Support from people who know what they’re talking about will help greatly in learning a framework simply because it’s so easy to divert away from the way the framework was intended for. Most frameworks have standards that should be adhered to.

If you choose a framework, congratulations! You’re more than likely to have an easier, faster time developing now and into the future. If you’re still yet to choose, think carefully and choose something you think will best suit your project now and into the future as it’s extremely difficult to move from one framework to the other.

If you’re learning, perhaps give working with a framework a miss until you’ve grasped PHP on its own.