Related Posts:
-The Demon of DMOZ
I’ve recently been involved in some extensive remodelling for a web application. Modelling applications is a big part of what I do for a living, but this one was special. It’s massive, and really, for the first time, I had myself thinking if we should use a framework to do the reconstruction work that would follow the remodelling. Of course, without wasting any time on the history of why we were remodelling (it’s a different subject, really) – I figured I should share when to use a PHP framework, as opposed to why to use it or why not to use it – there are many articles out there that address those 2 issues, but they are generally abstract by nature because at the end of the day, you have to, in the position you are in, decide whether or not you want to use one.
Before starting the framework discussion, though, you must ask yourself if you’re using any particular kind of software architecture. In the web world, you’re most likely better off using MVC driven architecture or some variation of a three tier architecture. This is important, because the popular PHP frameworks (and probably all the PHP frameworks) including CodeIgniter, Cake, Symfony, Zend, etc. are built on the MVC architecture.
I must preface the remainder of this article by saying that I’m not someone who breathes and lives code – I enjoy doing it, but I’m more of a big picture, pragmatic kind of guy. I like things to work, I like my apps to be scalable and I do write a lot of code myself, even if it is generally at the prototyping level or at the very focus’d level when someone in the team gets stuck.
Back to deciding on architecture. I’m involved in 2 kinds of projects – a big project which is essentially an in-house application. We have a dedicated team behind this, we have our own code base, our own requirements, and I didn’t think MVC was the best fit for this (I’ll explain why in a bit), so for this application, we decided to not use any PHP frameworks. The other side of the business which requires me to look after application development includes building smaller, custom web apps for other businesses. This development team, in particular, works on 12-20 different projects in a year. These aren’t long-lasting projects. We don’t need to maintain a dedicated code base for them. For these projects, it makes sense to use an existing MVC framework and rely on someone else’s code base (assuming you think they will continue to support it).
As with all things IT, web, or software – there is no absolute right. You have to do what works for you.
Why I decided to not use a framework for what we would consider a major web application is something that requires more discussion than I don’t think MVC works and I want our own code base. You see, to me, the web is rather simple. A web application consists of requests that the application receives from a user and a data or interface that is served back to the user who made the request. MVC is a nifty way of structuring your application code so you can separate the business logic from the database and the interface, but it does come at the expense of performance, and I think it is unnecessary. For most applications, the request is made and served by the view – so I think letting the controller make decisions is, well, tedious and probably unnecessary. If you make your view smart enough to know what the model needs and requires, you can effectively eliminate the Controller layer in the MVC sense. Note, however, that you can’t really do this if you are building a generic framework which defines a way for a community to code websites or applications. It’s an architectural preference (choosing to not use MVC), and whilst it has performance and preferential benefits, in terms of framework abstraction, it will leave something to be desired. But that is the beauty of being a software company that’s building its own product as opposed to a product that others will code with – we know exactly what our application needs to do and when, so generic is not really a concern. If any of that makes sense, it is in this kind of a scenario, where you don’t really want to use MVC architecture, that I think you don’t need to use a framework.
In all other scenarios, where you don’t have the budget to maintain a dedicated code base, or the need or desire to deviate from generally accepted architecture / design models, using a PHP framework just makes good, pragmatic sense.
At some point, I will make the effort to document the architecture that I am working on and perhaps discuss it. It’s a mixture of MVC and MVP, but in my view, more simplified. In fact, I think that it will make the shift for procedural PHP developers to OO programming easier as it attempts to approach the application in a linear fashion, whilst still splitting the practical code into views, business logic and a database layer.
For now, though, I hope that this brief insight into how I made the decision may be of use to you too.




