Intro
Below is an image I used on my presentation named "When PHP Framework Sucks" when I tried to explain what is happening when you bind too much with the framework. The image is the footprint of an apartment, with no common angles in room corners. So as you might already imagine, when you move to such apartment, you have to build your furniture custom to the shape of the angles of the room. Otherwise, you won't be able to equip your new place with standard furniture you can find on the market.
Let's make this case even worse. Let's say you move to the new city, you don't have many options to choose, and you picked up this apartment. It is empty, and you start to equip it peace by peace. After a couple of years, you decide to move to another apartment. But what you do with your already existing furniture? You have to throw it away and get a new one once you moved to the next apartment because the new one has all new room properties, this time just standard one, so your "custom" furniture does not fit anymore.
Impossible to change framework
Custom furniture is the perfect example of how developers shape their application around the framework and then they can't use it anymore in the other environment (other framework or libraries). Frameworks push you to structure your application in a specific folder structure, which is not bad by itself, but once you consider the framework change, it might be an obstacle. You might not change the whole framework as it is not what's happening very often, but sometimes just same framework, but different main versions completely make your app useless. I guess that everybody remembers migration from Zend 1 to Zend 2. I never heard of a success story, that one company accomplished that task.
Conclusion
That leaves us with the conclusion that every time a company or developer have to change a framework, she/he or company is pretty much forced to rewrite the whole application. Big refactoring or system rewriting is especially problematic with big systems which already earn a profit, and you can't just let it aside while you rewrite it in a new framework in peace. That's what I saw so many times in my career, that companies were unable to upgrade because of framework binding. They use to call that "Legacy problem" as that was something which "just happening over time" and you have zero control over it. Not many time I saw companies which enforce any DDD (Domain Driven Design) and forced the separation of their business from tools since frameworks are essentially just tools.
My discovery
I personally believe, and I already proved it, that separation from framework brings long-term financial benefit to the company. No matter what new framework version brings, or do we want to integrate our component with other framework or library, we can do that without any pain, but only if we separated our business logic from the framework. I recently had a presentation of my project which potentially can live as long as PHP lives (and not drastically change). The project is fully equipped with 100% unit test coverage + behavior tests to ensure that the list of features always works. Also, the project is so independent and abstracted from the framework, that we can appy it into another framework in a matter of one week. My company believes that this project gonna live for longer than five years, which already brings us to the point that we won't have any 'major refactoring" or "big rewriting." So if this not prove financial benefits I can't find any more obvious example.
Top comments (14)
That is so right at so many levels: When I was a youngy PHP developper, I discovered Laravel and everything lightened up in my head. I was so happy to be so productive (at the time, Laravel just went 5.0). And then, they released 5.5, and removed support for PHP 5.6 (which is a great thing I guess), but then changed their folder structure at Laravel 5.3, and so on... So many breaking changes. Then I watched this talk when Rasmus talks about framework fatigue and say that nowadays, framework are so inclusive, you get to build an API, but you also have Queue Jobs, Mailers, View engine, ...
I think like you guys, I come up to a point when I need to step back and choose my tools and not my framework (maybe PhalconPHP is the answer, maybe Symfony Flex, or something more brutal like composing our own framework).
And then you talked about DDD, and I wanted to know if you have good resources to start with (maybe on dev.to?).
Cheers.
You should check out the fat free framework. Chances are that you'll like the minimalist approach.
Couldn't agree more myself (although I am a Node dev). I always create a
*-coreusing DI,*-servicesand*-frontendpackage to combat this. Also, using Node, that enables you to use the functionality on the frontend with 0 adaption, which is awesome!Nearly every php application I work on as a contractor is badly written. The main problem is that developers don't understand the model part of mvc. They put the logic in the controller or overload the DI because they dont know what a design pattern is. The hard part is explaining this to a client who has spent thousands developing a brick
Maybe there is a problem with structuring web apps that way, if a majority of programmers don't understand how to do it.
MVC was invented for graphical user interfaces in the xerox days and dependency injection is handling dependencies in the opposite way that most programming languages are designed.
...and all of this, on a language that was meant to be a template engine.
You're right about Zend 1 to 2 migrations. I maintain a Zend 1 application at work which when I inherited it, had most of the functionality stuffed into fat controllers, and while I have improved the situation it's going to take an awful lot of work to migrate it away from Zend 1. I expect it will be years before it can be fully migrated.
I'm not a fan of this idea after seeing it implemented in several projects for several years. I've seen projects not being developed to their full potential just because people spent an absurd amount of time trying to keep themselves away from the Framework.
If the Business is expecting the application to grow and they do not want to be tied to a specific Framework, it's better for them to create their own framework in the first place... one that they can control, that's able to grow with the requirements.
Bear in mind that most of the times there is just not enough time or resources to make the perfect architecture from scratch. That's when you want to use a Framework. You let the Framework make standards and take the decisions on how your code should be structured. Only when you recognize this and start to code following the Framework Conventions, you will be truly reaping the benefits of the Framework.
When you find the troubles that you're speaking about (painful migration), I believe it's more related to the way you make your own code than the Framework itself. This post in Reddit explains it better.
reddit.com/r/PHP/comments/3bmclk/w...
I have been using an approx ~1000 line framework i've written, and for years haven't found a good reason to switch to anything else, every time i've looked.
There is always a lot to learn, which doesn't match up to the base language i've been working on for a decade. The syntax is always longer. There's always a requirement for more layers of abstraction than i'd like to deal with, for performance reasons and code comprehensibility reasons.
I've been trying to understand why frameworks are so great for many years. I'm convinced that they are just a fancy way to get everyone to code roughly the same in a language that gives you an ungodly amount of freedom.
I agree completely about keeping the business logic separate from the tools layer. I'll go one step further; if you want to ensure the site is maintainable I would avoid using any 3rd generation language for the customer-facing part of the site code, as it's always complicated to pick up a project years down the road. Think of something along the lines of SQL instead. I am a passionate believer in the power of DSLs to act as the bridge between human and machine. And if anyone thinks this is impractical, let me assure you it's quite easy to write a competent DSL. I've built them in Java and in JavaScript and I would never claim to be the sharpest tool in the box.
Basics versions of many php frameworks like symfony, cakephp etc have short life cycles and when release major version upgrade they will have breaking changes that make migration hard. If you have write well documented code, you make continues refactoring in codebase and make use of long life cycle frameworks it's ok.
Weird example there though, that change in Laravel 5.7 doesn't really affect anything whether you upgrade your older app or make a new one, why would that in particular set you on this path?
The kind of enthusiasm i see around Laravel kinda reminds me of how Apple products are thought of.
Maybe i don't see it, and Laravel is really freakin' good and i'm really dense..
Well.. i guess you didn't heard of symfony :-D
Quite opposite, I work with Symfony on a daily basis. Why do you have such an impression?