DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Microservices With Apache Camel and Quarkus
  • Competing Consumers With Spring Boot and Hazelcast
  • RBAC With API Gateway and Open Policy Agent (OPA)
  • Observability Architecture: Financial Payments Introduction

Trending

  • Microservices With Apache Camel and Quarkus
  • Competing Consumers With Spring Boot and Hazelcast
  • RBAC With API Gateway and Open Policy Agent (OPA)
  • Observability Architecture: Financial Payments Introduction
  1. DZone
  2. Coding
  3. Frameworks
  4. 5 times faster than Entity Framework

5 times faster than Entity Framework

How bloated is Entity Framework, really - Let's find out!

Thomas Hansen user avatar by
Thomas Hansen
CORE ·
Aug. 27, 20 · Opinion
Like (3)
Save
Tweet
Share
6.26K Views

Join the DZone community and get the full member experience.

Join For Free

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 ...?

Entity Framework Database Framework

Opinions expressed by DZone contributors are their own.

Trending

  • Microservices With Apache Camel and Quarkus
  • Competing Consumers With Spring Boot and Hazelcast
  • RBAC With API Gateway and Open Policy Agent (OPA)
  • Observability Architecture: Financial Payments Introduction

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: