Timeline for Why should I use an ORM like Entity Framework Core?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 8, 2023 at 13:17 | vote | accept | Ian | ||
| May 23, 2022 at 12:00 | comment | added | Robert Harvey | You can think of Dapper as a modern equivalent of your ADO technique, except that it takes three to five lines of code to write a query instead of 20 or 30. Raw queries in Entity Framework work the same way. Dapper also has a CRUD extension, if you still want the 80 percent solution. | |
| May 23, 2022 at 10:07 | comment | added | Ian | I first started writing web apps with C++ and ADO, returning disconnected recordsets to ASP pages. SQL was hardcoded in the data access layer. It worked fine, without a hugely complicated ORM to learn about. I guess working with Dapper is like this. I'm just thinking maybe, for me, EF is a huge waste of time. | |
| May 20, 2022 at 15:50 | history | edited | Robert Harvey | CC BY-SA 4.0 | added 10 characters in body |
| May 20, 2022 at 15:48 | comment | added | Greg Burghardt | "EF is what I call an "eighty-percent solution." You would only write SQL and use raw queries for the 20 percent (or less) of data access that requires it." -- this is an important sentence. People regard ORMs as a 100% solution way too often. Getting the ORM to do all data access requires such intimate knowledge and such a large amount of time you are better off writing SQL and using the DB libs directly for some use cases. Just make sure it is properly encapsulated in a class or separate library to facilitate testing and reduce effort to switch DB vendors. | |
| May 20, 2022 at 14:57 | history | answered | Robert Harvey | CC BY-SA 4.0 |