ADO.NET Entity Framework or ADO.NET

Question

I'm starting a new project based on ASP.NET and Windows server.

The application is planned to be pretty big and serve large amount of clients pulling and updating high freq. changing data.

I have previously created projects with Linq-To-Sql or with Ado.Net.

My plan for this project is to use VS2010 and the new EF4 framework.

• It would be great to hear other programmers options about development with Entity Framework

• Pros and cons from previous experience?

• Do you think EF4 is ready for production?

• Should i take the risk or just stick with plain old good ADO.NET?

Answer 1

Whether EF4 is really ready for production is a bit hard to say since it's not officially been released yet.... but all the preliminary experiences and reports about it seem to indicate it's quite good.

However: you need to take into consideration what EF is trying to solve; it's a two-layer approach, one layer maps to your physical storage schema in your database (and supports multiple backends), and the second layer is your conceptual model you program against. And of course, there's the need for a mapping between those two layers.

So EF4 is great if you have a large number of tables, if you have multiple backends to support, if you need to be able to map a physical schema to a different conceptual schema, and so forth. It's great for complex enterprise level applications.

BUT that comes at a cost - those extra layers do have an impact on performance, complexity, maintainability. If you need those features, you'll be happy to pay that price, no question. But do you need that??

Sure, you could go back to straight ADO.NET - but do you really want to fiddle around with DataTables, DataRows, and untyped Row["RowName"] constructs again?? REALLY???

So my recommendation would be this:

• if you need only SQL Server as your backend
• if you have a fairly simple and straightforward mapping of one database table to one entity object in your model

then: use Linq-to-SQL ! Why not?? It's still totally supported by Microsoft in .NET 4 - heck, they even did bugfixes and added a few bits and pieces - it's fast, it's efficient, it's lean and mean - so why not??

Answer 2

EF 4 is now more similar to LINQ to SQL, in the good ways; it has the FK keys right in the object, has add methods right in the object sets, and a lot of other nice features. THe designer is much improved, and the major plus is that it works with SQL and Oracle, and maybe some others (as long as the provider supports it) instead of LINQ to SQL with only SQL Server.

EF is the future; the ADO.NET data services is a web service add on, plus it supports POCO and T4 generation, and any new features will support this (LINQ to SQL is maintenance only, and data sets won't be getting any changes any more).

HTH.

Answer 3

My advice is use both. At first I thought I would only use linq to sql and never have to touch ado.net ever again ( what made me happy lol).

Now I am using both because some things linq to sql(and any ORM like EF) can't do. I had to do some mass inserts and I did it first with linq to sql and to do 500 records it took over 6mins(2 mins for validation rules rest was inserting into the db).

I changed it to sql bulk copy and now it is down to 2min and 4 seconds(4 seconds to do all inserts)

But like marc_s said I really did not want to fiddle around with DataTables, DataRows, and untyped Row["RowName"].

Say my table was like 10 columns long and called Table A. What I did was I used linq to sql and made a Table A class( new TableA()) object and populated it with data. I then would pass this object to a method that created the datarow.

So linq to sql saved me some time because I probably would have made a class as I would not have wanted to pass in 10 parameters into the method that makes the data row. I also feel it gives a bit of typeness back as you have to pass in the right object to use that method so less chance of passing in the wrong data.

Finally you can still use linq to sql to call Stored procedures and that is like one line of code.

So I would use both when ever you notice that linq to sql (or in your case EF) is slow then just write a SP and call it through EF. If you need to do straight ado.net evaluate what you need to do maybe you can use EF for most of the code(so you can at least work with objects) and only for that small portion ado.net sort of what I did with sql bulk copy.