Let me tell you a dirty little secret. Entity Framework is bloatware. It's unbelievably slow, and carries enormous amounts of overhead. Even ignoring that it results in lousy architecture, with (often) AutoMapper profiles scattered all over the place, and "magic transformations" between POCO types and your database model, often based upon ridiculously slow reflection invocations - If you're to follow the tutorials, and implement the "best practices", it still performs at a level not even worthy of a "hello world noob developer". Watch the following video, and you might be surprised.

Then realise, that Magic will for each and every HTTP request, load a file from disc, parse it as Hyperlambda, create a graph object out of the file, and using the names of the nodes as a lookup into a dictionary, resulting in retrieving a type, create that type using my IoC container, cast it to an interface, and invoke its "Signal" method, passing in the subset of my previously parsed graph object(s). Still this process is 5 times faster than creating the exact same controller endpoint in C# with Entity Framework, following the "hello EF world" tutorials ...

Now of course, the only sane conclusion from the above conclusion, is that Entity Framework is bloatware - Especially considering its compiled CLR code, not able to outperform the above process.

Many of our industry's "best practices" are way far from just that. AutoMapper for instance, brilliant tool, until you start realising you're returning megabytes of data back to the client, because one of your controller endpoints just needed "one additional property, resulting in an array of graph objects, no other endpoint required". 9 out of 10 endpoints only used a fraction of the data returned, but because of EF+AutoMapper, 10 out of 10 endpoints will suffer its overhead :/

Not to mention that all the benefits of statically compiled code: Bingo! Straight out the window! Due to "magic transformations" between your DB model and your HTTP DTOs. Try finding that bug in your AutoMapper profiles due to a "refactor property name", magically transforming from your EF model to your HTTP DTO model, and you'll understand what I mean.

In fact, I propose a change of naming conventions here. EF+AutoMapper should be called Magic, due to its many "magical moving parts". And Magic should be named "middle of the road", due to that it arguably contains less Magic than EF+AM ... ;)

What can I say ...?

Take me to your leader ...?