views:

421

answers:

6

I've read a lot complains about Entity Framework in .NET 3.5 SP1, especially about its ineffectively generated SQL. Those complains had prevented me from studying Entity Framework.

Now Entity Framework 4.0 has come out, which provide a lot of promises. I wonder if it's really a good ORM now, or still not yet? Is it worth to learn and use it in my .NET projects, instead of traditional SQL queries? Have you planned to switch to EF 4.0 yet?

Thanks in advance.

+7  A: 

You should really check out Julie Lerman's blog on EF4, she's at once enthusiastic on the product, yet technically correct. As per me, I can tell you that we have already used EF4 in more than a couple production projects with good results :-)

Edgar Sánchez
+7  A: 

One word: YES!!

Entity Framework 4.0 contains a huge number of additions and improvements, and with the additional templates for POCO's and self-tracking entities, it's definitely ready for prime time now.

If you want to, you can even go so far as to define your entire EF "model" in code - no *.edmx file at all - looks and feels a lot like Fluent NHibernate. You have lots of options with EF4 - and that's a good thing, and a sign that the ADO.NET team really did listen to the community (and work very hard to make those things a lot better now).

In addition to Julie Lerman's book and blog, you should also check out the ADO.NET EF4 team blog - it contains very useful and helpful hints and tips.

This blog post in particular might be of interest to you:

marc_s
+1 - I agree...
KristoferA - Huagati.com
*"...you can even go so far as to define your entire EF "model" in code - no *.edmx file at all.."*Just to clarify, as of today, that's only available as CTP and will be a standard feature of EF 5.0.
Morteza Manavi
Yes, the "code-first" approach is a CTP for now - but it might show up in VS 2010 SP1 - EF 4.0 SP1 :-)
marc_s
What is "a CTP"?
Jeff Walker
@Jeff Walker: CTP = Community Technology Preview - something like a "beta" program - something that's "in the works" and not finalized / finished / polished yet, but typically quite functionally complete
marc_s
Yeah, code first is a major improvement, but it's not here yet. CTP's are just previews, and quite commonly undergo major changes (e.g. nullable types in C# and PLinq) before being released. They don't have the aim of being mostly-complete that beta's do; they're more experimental and forward-looking.
Eamon Nerbonne
+2  A: 

Yes, EFv4 (in .net 4) is in a completely different league than EFv1 (in .net 3.5 SP1).

EFv1 had a lot of limitations and it sometimes generated horrible T-SQL.

The TSQL generated by EFv4 is fine as far as I am concerned; sometimes it has a bit more nesting with subqueries than needed but that is a cosmetic thing that only affects human readability...

KristoferA - Huagati.com
+1  A: 

If you need ORM and you are limited to .NET Framework then yes EF v4.0 is major upgrade and it is much better than EF v1. But on the other hand it is still only second version and a lot of problems are not solved yet. Also mentioned code first development (no .edmx) is only CTP version which is not ready from production usage. But I believe you can successfully use EF in any kind of project and you will still get some added value in quicker development.

Among limitations you can think about:

  • Limited mappings
  • Worse experience with EDMX in shared environment
  • Bad experience in disconnected scenarios
  • No build-in tracing
  • Limited extensibility, no hooks
  • etc.
Ladislav Mrnka
A: 

No for now

Considering the limitations and previous experiance with EF in 3.5 sp1, I would suggest not to consider EF till it stabilises.May be by version 5 , it should I supppose. It would be better if you carry on your design with LinQ to SQL till then.

Happy Programming...

Vimal Raj
Have you given EF4 a serious, good look? Pretty much all the problem from v1/v3.5 version are indeed already solved and no longer an issue.....
marc_s
hes talking about EF4 not EF that was realeased with 3.5
John Nicholas
@marc Why I suggested to wait till EF5 , is because I was into many troubles just because of adopting EF with 3.5sp1. Its true that I haven't given EF4 a serious good look as I was a bit scared with my previous experiance. So from the posts I am having a positive feel towards EF4 and I m gonna definetely try it.
Vimal Raj
+1  A: 

EF4 is still missing pretty major components. However, why are you waiting for the perfect product? It's never going to be around. EF4 is quite useful even if it has a few rough edges.

You can use SQL and EF4 side-by-side, so if you happen to run into a scenario where EF4 makes inefficient code or simply doesn't support something, you can always use plain old ADO.NET. The entity framework actually supports constructing entities from DataRows, so you can fairly easily plug the results of such a exceptional SQL query back into your normal program flow. Where EF4 shines is in the more normal scenarios where type-safety & intellisense come into play.

Using the entity framework does entail a bit of a learning curve, and the earlier you start, the better. Despite the fact that EF4 isn't quite there yet (in my opinion, anyhow), I'd say: go for it! Use it for a few small corners of your app to get a feel for it.

You can construct an entity connection over an existing (unopened) SqlConnection which is opened by the EntityConnection, and using TransactionScope then permits you to share a single non-distributed transaction between EF and ADO. Taken together, that means you can use small bits of the EF as drop-in replacements for normal ADO queries, transactions and all, as part of the same connection (i.e. without extra overhead from the server's perspective).

Eamon Nerbonne
What "pretty major components"?? Care to elaborate a bit more??
marc_s
In short: see the other posts. My point is that the limitations (which exist) aren't reason enough to pass up the advantages (which also exist) since it's pretty doable to use side-by-side with ADO. Some limitations are lack of POCO, limited designer support, lack of batch updates, poor integration with views, lack of support for "non-core" operations (e.g. INSERT OR IGNORE), and thus suboptimal performance in update scenarios. Oh, and the API is overcomplex on the matter of entity versioning. Anyway, most of these aren't issues for 95% of all queries, and it's OK to use the odd fallback.
Eamon Nerbonne