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 bi...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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!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.
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 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.
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?
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..