2 ms·
I agree about the limitations of ORMs. However I have had great luck with using an ORM to load up the database and data, and then having a unit test that calls
by btilly 4y ago
I agree about the limitations of ORMs.
However I have had great luck with using an ORM to load up the database and data, and then having a unit test that calls the function which does raw SQL in the middle. And now the raw database tests are integrated with the unit tests for the rest of the environment in a way that keeps them synchronized with the application code that also interacts with the same database.
And, of course, the limits of ORMs do not change the fact that they have use cases.
- DaiPlusPlus 4y agoThere’s ORMs and there’s ORMs - at one end you have the (reprehensible) Active Record anti-pattern, at the other end you have EF Core extended with one’s own build-time type generation - they’re both “ORMs” to everyone involved, but they’re totally incomparable. …not to say they that EF Core doesn’t have flaws (it does, and they’re legion) but the ORMs of today are nothing like the ORMs of the 1990s… or even like 2010’s NHibernate.
- btilly 4y agoI agree, but I still haven't seen an ORM that handles analytical queries well. Which means that, no matter what the other merits of the ORMs may be, there are important use cases where raw SQL is the only realistic option. Which brings us back to how to test that code.