Many arguments accept string|array, there is many methods to do similar things which makes it hard to keep conventions without good tooling. APIs are too flexible: the API of many objects is just too flexible.It should never have been a thing, dependency injection is such an important concept. The only advantage facade have is to be able to use them like it was a singleton, but that’s exactly what we don’t want. We can change the service and break everything, there is nothing that enforce us to follow anything. Yes it’s possible to mock facade but it’s hacky and it’s not based on a contract.
It’s yet another part of something that we cannot mock with east, it creates a blackbox and pushes to not use dependency injection. Not only the facade pattern has nothing to do with what is implemented in Laravel (see, thanks Taylor for the confusion) but it’s also a terrible practice. Facade pattern: Models/Service/Tools, almost everything uses the “facade” pattern.Using the data-mapper (repository) pattern is better outside MVP/little applications. It’s also hard to test because it’s coupled to the database. While this is “ok” for small apps, it makes it hard to unit test, hard to decouple and doing too many things. Models hold a state and are tight to the database.
well, model but also infrastructure layer, because they implement the Active Record pattern (which breaks the Single Responsibility Principle).
Models is a mixture of 2 concepts: In Laravel models are. You need to open files from the framework to understand how it works, instead of using the contracts (inputs available). Unfortunately the framework uses app() in many places which makes things act like a black box. Injecting dependencies is extremely important to be able to decouple the code, to be able to test things, to make it easier to compose. No dependency inversion: This is a pretty basic concept that should be understood by everybody. In the majority of the cases, using dependency injection would be the right way, to have logic in a specific class. You cannot remove a trait if you don’t own the code. It’s easy to bloat classes because it’s still a vertical way to add code, similar to inheritance. Traits: Traits are used everywhere in Laravel. (Related issue: ) (Occurrences of "Container::getInstance()": ). The Container interface is almost useless because event if we implements this contract, Laravel's container concret implementation will be used by the framework. Singleton usage: The container has a singleton and unfortunately this singleton is used everywhere across the codebase. I did use Laravel with 20 devs working on the same project and that’s how I learned how harmful and toxic this framework can be. I this post I want to explain why Laravel should be considered harmful for the PHP community. Over ten years ago, Laravel emerged, and with the release of version 4, it quickly became the most widely used PHP framework. Some years ago we didn’t have composer or namespaces, we have come a long way.įrameworks have always been available, but as time passed, they began to offer more comprehensive tooling and better practices, with popular options like Zend Framework, CakePHP, CodeIgniter, and Symfony. Having worked with PHP both as a hobby and professionally for more than 10 years I saw a lot of progress in community to use best practices.
0 kommentar(er)
