Originally published by Dan Patrascu on: http://danpatrascu.com/all-that-glitters-is-not-gold/
“All that glitters is not gold” is a well-known saying, meaning that not everything that looks precious or true turns out to be so. Does this also apply to software development? I’m fairly sure it does, since being attracted by glitters comes natural especially when you are not a very experienced software developer. As I do not considered myself a very experienced developer, I’m not afraid to say that I was attracted by glitters more than once and learned the hard way that all that glitters is not gold. Let me explain!
I was at the beginning stages of my journey to become a .Net developer when I first got in touch with Entity Framework Core. I found it really exciting since it was fairly easy to set up and it abstracted all the SQL part away from me. Let’s be honest, when you’re still learning the basics, having a tool (well, ORM in this case) that makes things easier is more than welcome. And it’s also not wrong in my opinion if one remains aware that SQL is still something that a developer needs to learn. The impression that Entity Framework Core is like a card in the magician’s sleeve that I can always pull out when working with SQL databases did however stick in my mind.
When starting to work on real projects however, even if personal ones, I have found out that, well Entity Framework Core is not really the answer to everything. I found out that in some circumstances, Entity Framework makes one or more transactions to satisfy sometimes even simple requests which, of course, adds a lot of latency. For small application this might not be a big deal, but for larger applications with many requests, this becomes something to be aware of. Also, modeling many-to-many relationships, especially when using a code-first approach is not necessarily very trivial. Sure, you can create model classes for the joining tables (called also bridging tables) and than configure the many-to-many relationship via the Fluent API, but this is not very intuitive and maybe hard to grasp for beginners. Sure, there are a lot of other ways to optimize Entity Framework Core but all database architects that I met were always kind of worry when confronted with the possibility to use Entity Framework Core.
I then discovered other ORMs, like Dapper which allows you to easily work with stored procedures. Generally it is more lightweight than Entity Framework Core, it yields a better performance, but it lacks a lot of features that EF Core provides. Writing SQL is once again a very important skill with Dapper. So one would have to spend far more time to get Dapper working and maintain everything in sync when changes might occur.
The strange thing however comes now: Entity Framework is not bad. Dapper is not bad. NHibernate (of which I have basically no experience) is probably also not bad. Does this contradict everything I’ve said before? In my opinion, no. But they are also not golden. As a software developer one would have to learn all the good parts about all the tools that might be used, as well as all the bad parts. No tool is a card in a magician’s sleeve that you can simply pull out everytime, regardless the exact scenario, application requirements, forcasted load and usage.
A good developer should always be aware of all pros and cons and should have the necessary experience to choose everytime the solution that accommodates a certain and very specific scenario in the best possible way. Sometimes it might be Entity Framework Core, in other occasions it might be Dapper or NHibernate. Sometimes it might be Angular, at some other points it might be React, Razor or anything else. Sometimes it might be Microsoft Azure, other times it might be AWS. Sometimes it might be SQL, other times it might be No-SQL. And when you start realizing that you have less and less such cards down your sleeves, it means that you gain more and more experience as a software developer.