DEV Community

Cover image for Why I Dislike Entity Framework for REST API Development

Why I Dislike Entity Framework for REST API Development

José Pablo Ramírez Vargas on September 19, 2022

Originally published @ hasnode.dev. Preface I have been a backend developer for easily 14 years, all of them in .Net, whatever versio...
Collapse
 
scorpio69 profile image
Manik

I do agree up to an extent as some of what you have mentioned reflect in my real world projects. I am ADO and ADO.NET person and I started developing software products from 2002 onwards, since 2016 I have been using Dapper and EF in my projects. I designed a project template which use both ORMs but implimented seprate pipe lines using clean architecture and now every time I have a new build it only take me 5 minutes to spin a new API and get my team to start developing.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

Exactly, there are so much better ways to go than EF nowadays, right? It is just a matter of putting some thought on your design and add on your past experiences.

Personally I work with the repository pattern where I enclose Dapper whenever the customer and the project allows (some enterprises are married to EF, unfortunately). Then, with super-dumb repositories I do unit testing from the services layer up and free myself from the oddities of unit testing code that depends on a database.

Collapse
 
scorpio69 profile image
Manik

Hi @webjose I am on the same page as you. I normally have two projects Libs one for Dapper Repo and EF Repo and both are dum repositories. Basically, Controller->ServiceLayer->EF or Dapper and if I have two or more DBs which might produce one DTO from 10 different tables, I prefer to use Dapper. In the past, I had the opportunity to work on a very large project where multiple Dev teams were working on different bits of the project and we had a lot of redundant code, so I recommended Generic Repos and immediately I got a lot of push back from Tech leads about it being not very efficient, but in short it made life for every one lot easier.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Agreed. I work with "model features", where each feature is represented by an interface. By doing this, I can write generic repository base classes based on the interface, and then simply inherit from the correct repository according to the features boasted by the model. It is super efficient. Exactly the opposite your tech leads told you.

Cheers.

Thread Thread
 
scorpio69 profile image
Manik • Edited

Hi @webjose I have read about Model Features and done some practice code but will love to see a real life or indepth example. Any blog you can recommend?

Thanks.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Hi. No recommendations. I have never seen anybody doing it. I think I am the only one that does it, and because I have never blogged about this, I don't think you'll find anything. I will try to write something up within 30 days.

Thread Thread
 
scorpio69 profile image
Manik

If you can find time if not still big thank you it was good to share thoughts.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Hello @Manik, I finally wrote about Model Features.

Happy reading.

Thread Thread
 
scorpio69 profile image
Manik

Hi @webjose read your article. I really appreciate the time you took to explain the concept with really good example code. My Generic Repository is about 90 percent as you explained, but upwards in the service layer and other parts of the project, I was not using the Model features concept. I have started work on a template project to see how it works across all layers.

Thread Thread
 
webjose profile image
José Pablo Ramírez Vargas

Good luck! Glad you liked it.

Collapse
 
minhtrn98 profile image
minhtrn98

Disagree about Unit of work is meeningless in API. Any where you develop always need to deal with multiple model in the same time.

Collapse
 
webjose profile image
José Pablo Ramírez Vargas

Hello. It is true that you deal with more models. It is also true that you can do this without the Unit of Work pattern, especially if you have one implementation that is so intrusive.