From the course: MVC Frameworks for Building PHP Web Applications

Why use a framework?

From the course: MVC Frameworks for Building PHP Web Applications

Start my 1-month free trial

Why use a framework?

- [Instructor] As you likely already know, PHP is a solid application development platform. It provides services for handling email, database interaction, and more. Because of its power and flexibility, it's easy to get in there and start coding your application without using any framework at all. So what is a framework and why use it? That's a good question; let's have a look. Coding in straight PHP works, but if you're not careful, there are a number of things that can happen. One thing you can end up with is what we call Spaghetti code, which are long, single files of code, often containing different elements including the view, including access to databases, and all kinds of different code in one single file. It's easy to have Redundant work, which means you have a lot of work that is doing the same thing. Different files of code that basically perform the same function, perhaps in slightly different contexts. But if you ever want to change how they all work, you have to go in and change them in every single place and it's easy to make mistakes. We all know the disadvantage of disorganization. The larger an app gets and the more developers you have working on an app, the more of a problem this disorganization can be. When you have an application that's written in Spaghetti code and Redundant code, it can be very difficult to reuse things from one app to another app. The larger an application gets without an organized framework, the more difficult it can be to make changes. If you change one thing, you're very likely to break another. It's very difficult to test different aspects of your code when things aren't cleanly organized. Often times, when you're not using an authentication, we need to code things like authentication from scratch instead of using pre-used, pre-built, pre-tested code. And finally, working in a team environment when you have an application without a framework can be extremely difficult not to step on one anothers' toes. Because of all these issues, people came up with the concepts of Patterns and Frameworks. Frameworks can help to overcome all of these problems in a number of different ways. Primarily, Frameworks provide a recipe for how we're going to create an application and break it up into logical pieces. When things are broken up into logical chunks it's a lot easier to test these separate chunks and reuse them in different parts of the application or even in other applications. Changing things can be much easier, for example if we're using a single element to provide an interface for something, we can simply make one change to that element and anywhere that interface element is being used will instantly be updated. So we change things in one place and it can change it in multiple places throughout our application. Frameworks provide and organizational structure. So this is a nice clean way for things to be broken up and found within your application. Virtually all of these Frameworks come with pre-built and pre-tested tools that you can just plug into your application. This can help with things from setting up databases, to authentication, and a lot lot more. Another really important advantage of using Frameworks is that it makes it easier to work in teams. When you have a Framework, all of your files are broken up into logical constructs, so one person can be working in one area and another person working in another area, and you don't have to worry about bumping into each other all the time. So a likely question to ask is, "If there's all these advantages to using a Framework, do we always need to use one?" Well not necessarily. In some smaller applications you might be just fine building things in straight PHP. Often times when we do this, when we use Frameworks, we have to break up code into very many chunks. So doing something like a simple form submit and action page, if that's all we need to do, we would have to break that up probably into nine or ten different class files, which might be too much work for a very simple application. Additionally, there's a learning curve for these Frameworks. Often times, the learning curve is something that we should overcome, but in certain instances, we might be in such of a rush that we can't take the time to do that. And finally, there might not be a benefit in a very, very small application to over-organizing your code. The end result is that: in an application using a Framework we have our code broken into a fashion that's more organized, easier to reuse, and prevents us from redundant programming; we can test these smaller pieces; we get a head start before using services included in the Framework. It can also be easier for teams to negotiate working on overlapping functionality because of these more granular pieces of the application. Ultimately, Frameworks lead to better organization of code, which in most cases, can make our application developing experience less painful.

Contents