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)

Answer 2

You seem to have a mix of requirements and a mix of solutions.

I normally rate each requirement with an essential, nice to have, not essential. And then see what works.

I agree with what @marc_s has said, you can have the best of both worlds.

The only other thing I would say is that if this solution is to be around for the next 5 years, have you considered Unit Testing?

There's plenty of examples on how to set this up using EF. (I personally avoid ADO.Net just because the seperating of concerns is so complicated for Unit Tests.)

There is no easy solution. I would pick a feature in your project that would take you a day or so to do. Try the different methods (raw sql, EF, EF + Stored Procs) and see what works!

Answer 3

Take an objective look at CSLA - invoke the 'DataPortal' and check out the call stack.

Next, put those classes on a CI build server that stores runtime data and provides a scatter plot over a series of runs.

Next, look at the code that gets created. Ask yourself how you can use things like dependecy injection in light of classes that rely on static creators with protected/private constructors.

Next, take a look at how many responsibilities the 'CSLA' classes take on.

Finally ask yourself if creating objects with different constructors per environment make sense, and ask yourself how you will unit test those.