4 ms·
I work for an enterprise in-house web application, where over time we have a ton of tables, like over several hundred unfortunately. Writing queries for each an
by jamamp 5y ago
I work for an enterprise in-house web application, where over time we have a ton of tables, like over several hundred unfortunately. Writing queries for each any every table and manually mapping those to objects sounds exhausting. EntityFramework helps a lot with that, for CRUD operations.
Additionally, I think unit testing would benefit from an ORM as well. Instead of calling an actual database, you can easily have an in-memory database with an ORM with mocked data. Though, I suppose that is technically possibly with straight SQL queries as well, but I imagine it's easier with an ORM.
- furstenheim 5y agoThe main problem with in memory databases is that they are not the same database. I've had several issues which I had to find a fix that worked on one database and was legal syntax on the other. Say maybe one database allows force index but in memory does not. I've even seen one database layer for in memory and a completely different one for real database. That means that your unit tests are not really testing your production code
- zaybqp 5y agoYou can also make the same argument about ORM's mock DB layer.
- zaybqp 5y agoHow would it be easier with ORM when switching to in-memory database for standard SQL is just changing connection string?