No one always needs a framework
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
Christopher Alexander's view of architecture is that forms should be a function of their contexts : a solution can vary wildly depending on requirements set with the customer (or even unspoken ones).
A corollary is that there is no "one true way" of developing software. The evolution of methodologies, just like the evolution of life, is not a pure improvement process; instead, it is an adaptation to the different contexts such as the increase in performance due to Moore's law and the birth of the Internet.
My corollary is that statements like "you should definitely use A framework, even if it's not the X framework I endorse" are suspicious in my head.
Freedom from frameworks
Two years ago I attended Matteo Vaccari's talk on web programming "free from frameworks", which set in motion a general suspect towards an adoption of frameworks as radical as the selection of programming language. You can do wonderful things even without relying on a framework, if you are able to play with objects and reuse them.
I have now experiences in contexts that called for no framework usage (because PHP frameworks didn't exist at the start of the project) and that at least survived and made money for years.
The principal things you notice in these projects is that there is no monolithic frameworks logically contained all the code: code is directly exposed as HTTP pages and endpoints, instead of being called from inside some controller or view script.
Explaining a bit more about this context, these are the peculiarities with respect to the typical PHP project:
- The product under continuous development is hosted internally, and sold as a service branded by the company. This means that the aim is never to cut costs by reusing open source code, but just to maintain our ability to intervene on features.
- In this domain, it is more important to understand business requirements and domain-specific logic instead of quickly setting up user pages. In particular, lots of functionality is exposed via web services: forms, templating and lots of stuff goes away when you're working most of your time on APIs instead of HTML pages.
Thus I experienced that PHP frameworks aid in producing many pages in the front end, but not much in the inner gears as design is less dictated on the inside of an application; and they lower costs, while the focus of a project may be on increasing revenue.
I think some of the advantages of Your Own Architecture with respect to a framework are overlooked.
- The freedom of configuring your object graph: you decide which objects are needed and how they talk to each other. You can insert decorators or other objects at the right place.
- You can introduce domain-specific factories and interfaces, instead of Branded_DI_Container and Framework_Database_Object.
- You have the freedom not only to creating but also of reengineering pieces as you like: so you don't have to keep the debt of other people, but can clean up an architecture if the context changes or to adjust its fit.
- You have no surprises: all the behavior of the application comes from code that you wrote, and not from some defaults. This behavior is not spread around, divided between your objects hooked into the framework and the rest of its code.
There are already many articles on the benefits of frameworks, so I will cite only one of the issues of creating your own infrastructure code.
This problem is that of possible technical debt. When you adopt a framework, no one can deviate very much from their architecture and object interfaces; when designing on your own, you cannot borrow design from someone else.
This is very beneficial if all your programmers are object thinkers with 5-10 years of experience in design. But since there is no predefined structure, the result depends widely on the ability of programmers, in the good and bad case. You can end up with a resilient object graph produced by reusable classes and easy to change, or you may produce lots of monolithic procedures which may have been avoided by following what a OO framework dictates.
So favor composition over inheritance, but favor framework-based code over procedural balls of mud that reinvent the square wheel. The decision to go without a framework must be conscious, not an irresponsible one taken because we don't know how to use it.
You can still use frameworks as libraries with less hassle; but think before deciding to give up all the control on your application.