views:

316

answers:

3

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!

+1  A: 

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.

Mendelt
Would you plz check the question again, I edited. Thanks in advance
Galilyou
Thanks Mendelt, after a long look at EF and NHibernate, accepted! :)
Galilyou
A: 

Regarding EF things are about to change to THE BETTER! :) EF4 is just around the corner and even though some voices still complain I don't see why they bother. EF has finally become maybe not mature it's only been in the works for a couple of years but at least a reliable and flexible framework.

mhenrixon
+1  A: 

Developers had many grievances with Entity Framework 1.0 (.NET 3.5 SP1). The current release for EF 4.0 (Version 2 but so called because it's released as part of .NET 4.0) addresses most of these complaints. You can already download EF 4 Beta 1 if you are MSDN subscriber.

The Entity Framework Design team and the ADO.NET Team blog have a recent series of posts which talk about the various scenarios supports in EF 4.0 the biggest of which are Persistence Ignorance and POCO support, N-Tier support, T4 templates to name a few. TDD and Data/Model/Entities First are also supported by way of the aforementioned changes. Lazy loading is also there.

aleemb
I'm trying to apply it in a real project, i can't use VS 2010 Beta for real projects (company policy). Any clarifications about the current release?
Galilyou
@7alwagy, you may have to go with Linq to SQL or the EFPocoAdapter which is an interim staging platform for EF 4.0 features which is available. I have used EFPocoAdapter and I haven't hit any walls with it and expect EF to be even better. There's always nHibernate if you can go with that.
aleemb