Why Is Doctrine Dying
I've been thinking over 2 years about this post. I wasn't sure if it's only a negative hype feeling or the real thing. It's still the same so it's time to write about it.
I'm not an expert in databases, so active record might be actually a useful pattern, even architectonically, but I don't favor it now.
But the main I see is that Doctrine is not evolving. Last useful feature was the 2nd Level cache in
doctrine/orm released in 2015. In meaning not a few-person feature, but a feature, that can influence most of the applications.
Would you be still using Symfony if the last feature was released 2 years ago? No, you would probably go for Laravel, Yii2, CakePHP, Nette or any other framework to see, if it works better for you. Because we programmers evolve and we need to do the same work in less time and work.
This has nothing to do with code quality, number of active maintainers or too few people contributing. Although all have a great part in an open-source life cycle.
To put you in my seat, I've maintained many own and foreign packages. They had difficulty to stay alive with the same amount of energy invested. Does that sound like legacy code to you? Yep!
I see this is rather a system setup. Like any other system, it can lead both ways - slow down, or speed up. Depends on the vector you prepare.
To demonstrate an example of how a system can go both ways, I will show you something nice to do when you die.
Do you need your liver when you die? Somebody else might does, but it depends on your country's default law system, what will happen to it.
- In some countries, you can save a person by default.
- In some countries, you are just dead.
Of course, you can write an extra card saying "Take my organs when I die", but who will actually do it?
Where is death, there is life. I believe Doctrine or any slowly dying project can be saved - by just a system setup.
"Where you are the best, there is no one to learn from, so you stop."
If Symfony would be the only framework, there would be no other choice, everyone would be using it. And Symfony would have no motivation to be better (better than who?).
I think Fabien was aware of that, so he wrote a series Create your own framework... on top of the Symfony2 Components in 2012, which promoted using only components of Symfony to create an own framework. So Laravel was made on top of Symfony components.
Now these 2 frameworks are pushing industry standard like never before. Awesome to watch!
There is no more powerful motivation than competition. Moreover in man's worlds. Missing one? Create one!
I see Symfony, Laravel and many huge projects using this pattern and I am profiting a lot from it. After ~8 years in open-source, I've tried too (don't judge, just try for yourself) and it's the best! Trust me.
Having Doctrine (or any other project) split in over 20 repositories requires a lot of work.
Now each repository:
- has own coding standard (if any)
- is tested on different database versions
- relies on the hope that new change won't break other 19 packages
- has different maintainer signature and standards
That's how you spend more work on maintenance than on feature very easily.
The last thing that might turn it to the right direction is Dependency Injection via Constructor, also called autowiring. In many projects I see, while consulting big companies, this pattern would save them from 20-30 % complexity they have now (when used properly). Just by using it from the start.
1,5 year ago, I sent a pull-request for a simple thing - having modular filters. It is actually just a single-service constructor injection implementation. Huge problem to integrate. And there is a lot more static code like
new SomeService that could be easily resolved with this.
I miss an evolution with Doctrine. When some packages are stuck for 2-3 years in one place, there is probably already a better replacement. Either on Packagist or in your mind.
As I mentor and coach teams to write better code with less work, I'd go against my own beliefs by putting a vendor lock-in their applications.
That's why I'm dropping support for my Zenify packages built for Doctrine.
- Zenify/DoctrineFixtures - use nettrine/fixtures or Nelmio/Alice instead
- Zenify/DoctrineExtensionsTree - use nettrine/extensions instead
- Zenify/DoctrineMigrations - use phinx or nettrine/migrations instead
When you take a step back, you realize, all this can happen to your project too. I recommend taking some time to reflect, where your project goes and what is the reason - you, company or project's system?
What do you think? Do you see prosperity? Or alternatives like NextrasORM or Atlas ORM? Or even different pattern than ORM? Let me know. My knowledge is very limited and I'd be happy to learn something new. Thank you!
❤️️ Do you find value in topics what I write about?
Support my writing by throwing a couple bucks at my Patreon