I am not a big fan of EF/Entity Framework. To be honest, mostly I hate EF. I have many valid reasons to hate it however I really don’t want this post to be the show of hatred against EF.
Until today I was using my own Data Access Framework. It was not the best of his class but it did its job most of the time and it was performant enough to serve as an infrastructure in many projects which are still actively being used by thousands of users everyday. However it is old and it is getting older. With new developments in technology, the rise of the .NET Core and Microsoft’s shift against Standard .NET Framework steered me to update my good-old Data Access Framework to embrace the new infrastructure. This library was so much shaped and forged with real world scenearios (most of them were with tears and pain of course) by the time that upgrading my old friend to rise and shine in this new brave .NET Core world would be very costly/expensive. Consequently (in order to not to invent the wheel twice) I started my journey of searching for a new library which is capable of accessing data in an ACID manner, mapping the entities, having a cache mechanism etc. So I would say I needed something: Simple, fast, easy, flexible and capable…
First Migraine with EF Core
I’ve read couple of articles that states EF Core is way much faster than his standard brother: EF 6. Decided to test it. Followed Code-First strategy. Created my classes, decorated them with some TypeMappings (and also used some configurations) all fine. However it took couple of hours to figure out where I modify the connection string and just another hour to understand one-to-many etc relationships and just another couple of days to understand Migrations… And lost hours trying to understand that “it is not an error, indeed it is a feature” things such as standard conventions… And this fast-pace-based (assume it agile) development strategy of Microsoft who is delivering new versions for every other day makes it really impossible to find correct solution to your actual problem. Just because a random internet post (or even the official documentation) which seems to be a solution is probably outdated or no longer supported. (Could you please imagine the frustration of a developer when s/he tries to find a solution to the actual problem, thinks s/he found the solution and the found solution was indeed outdated. Thug Life…)
Indeed I was occupied the with that estranged feeling of “not knowing what exactly is going under the hood” or “Hey! An Error Occured with following description: An Error Occured”. Every error message which were generated by my application was somehow related with EF, a false or outdated configuration of EF or just an untold story of EF. Learning curve was so steep that finally I quit.
(And just before I start telling my story with dapper, I would like to hit EF again: having such migration (in)capability in Code-First approach is the most terrible thing that I’ve encountered so far. Could you please imagine how stupid to have a new class for every tiny change in model??? You will probably end up with 100000000 cs files under your Migrations folder unless you do a merge!)
Dance with Dapper
Like every frustrated developer, I’ve started another round of a quest to find a flexible solution. And like every developer I’ve been acquainted with Dapper. Dapper was being marketed (not in monetary terms) as the greatest and lightweight ORM who were suffering under EF or any other non-performant hefty ORM tool. And I must admit: It is freakingly easy and lightweight. But…
Maybe it is too lightweight. As lightweight as writing your own query as hard coded. However idea of manually writing a sql query in 2020 is pretty terrifying… Just terrible memories of past arose in my mind where we were haunting those manual SQL Statement changes within the classes….
To overcome this “un-civilized” thing, there are other addon like extension libraries. These libraries are pretty neat which enables developers to access and play with their data easily. Hassle-free.
I mean promising… Dapper is really promising. It also keeps its word to be the easiest ORM in the market. I’ve used Dapper in some projects. It is still working flawlessly. But I slowly started asking some advanced questions (like multiple queries) and dapper fell short.
Found a lovely thing! RepoDB
So far so good. Easy to use. Flexible enough. Fairly extendable. It is more like Dapper than EF. But coverage and hard-coded-greediness is not present. Very well documented. To be honest, it was pretty fast too. I gave it a try and suggest you to give it a try.
I will keep you posted…