Dependency injection might be the worst of all programming techniques ever invented.
Discussion
He come?
Bit of a vague memory on that technique, but, in hindsight how many people really created more than one thing to inject.
Same thing with ORMs. How often do people switch databases on a project?
Being database "agnostic" has many other benefits then "being able to swap out the database". This is definitely not why they were invented and more of a side effect.
I am interested in hearing the argument. An ORM can certainly reduce boilerplate and protect against common security issues. Database migrations are useful as well.
I am, however, unconvinced that they are a net benefit. Some developers use them as a way to avoid having to write SQL, but SQL is dead simple and I have never met an ORM that was actually good at it. It generally means that the developer doesn't really understand what they are getting with their queries.
Also while an ORM might make 90% of your queries easier that last 10% might be downright impossible. Luckily you can just make stored procedures and more models in your code to match, but now a decent portion of your application logic is in your database and you have a mess in your code.
You actually made a lot of arguments in favor of an ORM already.
It's not about not having or wanting to write sql, even though this will still allow people to use a database that do not know sql at all. Let's not focus on that however.
Developing becomes a lot more straightforward and faster because you can focus on your objects instead of queries and parsing. Most people are not doing anything complicated (sql wise) and a good orm will make the same queries as you would. This removes a lot of boilerplate sql code.
You also would not want to litter your code with sql statements that make it harder to read. So you can choose to abstract them into their own library or something, but now you still have half an orm that you had to build and expand for every database interaction that you intend to do. It's basically the same reason why you would use templates. Nobody wants to do their formatted output in loads of print statements.
Because you do not have to use sql all over the place remodelling parts of your datamodel becomes a lot easier and more consistent.
I am definitely biased because i have been using ORMs for at least the past 10 years. In all those years at various clients using various ORMs i only once had to revert to writing a raw sql statement.
Most of my time i've used Django's ORM (python) and SQLAlchemy (also python) but also used Ruby on Rails' Active Record. If queries were slow they all offer tools to debug what is going on. Every time except once i have been able to change the ORM statements a bit to optimize.
The only time i would not use an ORM is either if the programming language or framework used would not offer a decent/mature ORM or if performance was the only important metric and could not be solved otherwise. Maybe in that case you would also not want to use python or ruby to begin with. In all other cases spend developer tjme is often much more expensive then spend querytime.
You are correct. Errors! But now you don't know what is causing them!
Yes.
“In practice the theory is different”
It’s good for textbook examples, but falls short for more complex, real codebases.
go on… how do you prefer to get dependencies into things? do you just encapsulate everything inside?
Linking?
where do you see TDD?
Isn't this a side effect of the programming language choice itself and not necessarily the technique ?
Makes sense that Google built a whole frontend framework on top of it.
Hard disagree. Your only alternatives are:
- A centralized service locator, that stops being feasible as soon as you have multiple context layers (like in games: root context, scene context, game mode context, world object context, individual contexts for different UI sections),
- Classes constructing their own dependencies, making them non-testable and creating long chains of constructor argument passing.
One has to write test! 😉
it is