Originally published @ hasnode.dev.
Preface
I have been a backend developer for easily 14 years, all of them in .Net, whatever versio...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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.
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.
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.
If you can find time if not still big thank you it was good to share thoughts.
Hello @Manik, I finally wrote about Model Features.
Happy reading.
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.
Good luck! Glad you liked it.
Disagree about Unit of work is meeningless in API. Any where you develop always need to deal with multiple model in the same time.
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.