should I use Entity Framework instead of raw ADO.NET

Question

I am new to CSLA and Entity Framework. I am creating a new CSLA / Silverlight application that will replace a 12 year old Win32 C++ system. The old system uses a custom DCOM business object library and uses ODBC to get to SQL Server. The new system will not immediately replace the old system -- they must coexist against the same database for years to come.

At first I thought EF was the way to go since it is the latest and greatest. After making a small EF model and only 2 CSLA editable root objects (I will eventually have hundreds of objects as my DB has 800+ tables) I am seriously questioning the use of EF.

In the current system I have the need many times to do fine detail performance tuning of the queries which I can do because of 100% control of generated SQL. But it seems in EF that so much happens behind the scenes that I lose that control. Article like http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html don't help my impression of EF.

People seem to like EF because of LINQ to EF but since my criteria is passed between client and server as criteria object it seems like I could build queries just as easily without LINQ. I understand in WCF RIA that there is query projection (or something like that) where I can do client side LINQ which does move to the server before translation into actual SQL so in that case I can see the benefit of EF, but not in CSLA.

If I use raw ADO.NET, will I regret my decision 5 years from now?

Has anyone else made this choice recently and which way did you go?

Answer 1

In your case, I would still choose EF over doing it all by hand.

Why? EF - especially in .NET 4 - has matured considerably. It will allow you to do most of your database operations a lot easier and with a lot less code than if you have to all hand-code your data access code.

And in cases where you do need the absolute maximum performance, you can always plug in stored procedures for insert, update, delete which EF4 will then use instead of the default behavior of creating the SQL statements on the fly.

EF4 has a much better stored proc integration, and this really opens up the best of both worlds:

• use the high productivity of EF for the 80% cases where performance isn't paramount
• fine tune and handcraft stored procs for the remaining 20% and plug them into EF4

See some resources:

• Using Stored Procedures for Insert, Update and Delete in an Entity Data Model
• Practical Entity Framework for C#: Stored Procedures (video)