Home/ Questions/Q 219913
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T18:53:22+00:00

EDIT: Guys, sure I meant Entity Framework not ASP.NET MVC, it was a typo

  • 0

EDIT: Guys, sure I meant Entity Framework not ASP.NET MVC, it was a typo most probably!

Yesterday I came a cross this article that lists some of the bad stuff with Entity Framework. And after doing some google stuff I found this one which basically is the defender here. These two posts discussed some major issues of entity framework such as:

  • EF is not a failure because it doesn’t fit TDD development
  • EF is not a failure because business logic goes into partial classes
  • EF is not a failure because it treats data as an important part of biz objects
  • EF is not a failure because it accepts that most people do data first development
  • EF is not a failure because lazy loading is hard – lazy loading can destroy performance
  • EF is not a failure because its design tools are 1.0 level
  • EF is not a failure because it has a poor strategy for merging into source control

Now the points that really concern me in the above list are TDD fitness, Lazy Loading leak, and Source Control issues.

And here are my questions:

  1. Can’t I unit test my application methods good enough if I used EF?
  2. What does it mean Lazy loading is hard? Is it unsupported at all by EF?
  3. What does it mean that EF does have a poor strategy for merging into source control? aren’t all the files gets checked-in and out like any normal file in the solution?

Hope this clears what I’m trying to ask here, and thank you guys for your assistance! Appreciate it!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Thanks for removing the typo from the question. Now I can make my answer a bit shorter too 🙂

    The Entity framework did not really offer support for the style of programming preferred by the TDD / SOLID / Alt.Net crowd. This is what the vote of no confidence is about. EF forces you to design your business logic around the persistence framework making it harder to test and maintain your business logic. On the positive side because of all the tooling around entity framework it allows you to get an object model and persistence layer up and running very quickly.

    In newer version of EF this has gotten better. I don’t know if EF 4 allows for persistance ignorant object models yet, this was the most important shortcoming. But in my opinion this does not really change the fact that EF was built for a different style of programming than the what the writers of the vote of no confidence want. EF leans heavily on tooling and steers you in a database centric way of building your software. The default way of building software is still create a database and generate your object model from that.

    I don’t think most of the issues surrounding EF are about what’s possible. You can always abstract away the EF part from your business logic and build your application test driven. The issues are about what style of programming is made easier. I think you should use the right tool for the right job. If you’re building enterprise software in a team that’s comfortable with a data-driven style of development you should use EF. If you’re building software where persistence is less important than business logic and you’re working in a team that’s familliar with TDD DDD, BDD, SOLID and all that stuff you’re better off using something like nHibernate.

    • 0