Entity Framework - the good, the bad and the ugly

     Anyone who's been living in .NET world has definitely heard about Entity Framework. First appeared in 2008, it's aim was to "eliminate the need for data access code". It's been 17 years now and I can tell that while the idea was great, the implementation is so-so at best and unsupportable at worst. If you have ever tried to debug a long running LINQ query you will know what I'm talking about. 

But it's 2025 now, so where are we at with this?

Let's look at some typical backend tasks: data loading from a csv file, running some read, update, delete queries against the data. That pretty much covers it when it comes to a database interaction in 90% of the cases.

With the results that I see we're still very very far from EF to be remotely fast for anything other than small(ish) datasets. Indexing helps, however there's still a massive performance difference between LINQ and SQL.

I believe the whole idea behind ORMs was to expedite the development time instead of making developers learn SQL, however my observations in the field show that this backfires quite badly unless you're using it for relatively small datasets, provided indexing is in place.  

Backend is where it's at.

Backend code, even though it’s not something that end user interacts with directly, is a crucial part of modern application development. A typical user is usually oblivious to what’s happening behind the UI but without the data in the back even the best UI possible is nothing but a shiny exterior.

Let’s look at what are the main parts of backend development are. For a second, let’s assume we’re talking about a full blown desktop or web application and not a standalone “glue type” script, though those are much more common nowadays, especially with the rise of cloud technologies.

Origins of data and where it’s stored. No matter where the data is coming from (APIs, files, streams) it usually ends up in a database of sorts. Database usually serves two main purposes: persistent storage (for retaining historical data) and retrieval engine. RDBMS (Relational Database Management Systems) comprise the most common type of databases used.

We have our data, now what? This is where the fun starts – you take the data (that “take” part is something that is usually referred to as “I/O”), process it (business logic), maybe display it on UI and either save it back to the database or send it out. Both db writes and sending data out are part of I/O functionality as well.

From above description you can see that a lot is going on besides the actual “work”,i.e. a lot of I/O code is running behind the scenes. Even though it’s supposed to be invisible to the end user it is absolutely not the case if it’s poorly developed and not performance tested. How many times have you encountered a web site which seems to be acting normally until the moment you press “buy” or “process” button and suddenly seconds turn into minutes and minutes turn into hours....

In our future posts we’ll look at specific issues and multiple ways of resolving them based on our extensive experience in the field.

Why optimize your code in modern day and age?

     Simple and obvious answer - for the code to run faster (duh!).  But does it really matter? It depends. Let's say your code runs in a cloud. In that case an optimized piece of code can save you hunderds, thousands and even hundreds of thousands of dollars depending on the scale it is running at. Keep in mind that there are certain features of each and every language that are baked in and it makes sense to think your use case through thoroughly before implementing it. Having said that, for a client side code even a small optimization could go a long way, especially when we're talking about something on the UI side - that would obviously improve usability.