When should entity framework be used?

Question

I'm new to Entity Framework and, of course, I have found few questions on SOF with regards to target use-cases.

Let me give you some information. I'm not dealing with different database vendors or different databases; one, and only one, SQL Server 2008 and the database has less than 30 tables. Do I really need to redo things and go with Entity Framework?

EDIT:

Thanks to James for fixing my question. So I'm assuming using EF adds up overhead and does some work in background which I won't know. This is MS working style so I guess my next questions are:

1. Does it affect performance as well?

2. Does it support hierarchyid data type?

Answer 1

The main reason for using entity framework (or any other Object-Relational-Mapper such as LINQ to SQL, NHIbernate etc.) is to get easier data access in your application. With EF you gain access to the power of querying through LINQ and simple updating by just assigning the new values to a .NET object, without the need to ever write any SQL code yourself.

Personally I use EF Code First with EF Migrations for green field development and LINQ to SQL in the cases where I have an existing database to build upon.

Answer 2

ORMs Object-Relational-Mapper such as EntityFramework should be used if you are doing interactive data manipulation, the typical OLTP app can obtain big reductions in the number of lines of code needed vs using something like the plain ADO.NET API (either with dynamic SQL or with Stored Procedure invocation). ORMs do have a performance penalty, but, in interactive systems, this performace penalty becomes negligible, on one hand, because of the big reduction in "grunt work", and on the other hand, because the element that generates the most performance penalty is the human interacting with the system

If, on the other hand you need to make heavy batch processing of complex stuff that will run taking stuff from some tables and putting it into other tables without any interactive user intervention then the perfomance penalty of the ORM approach becomes noticeable, under this circumstances, it pays off to avoid taking things out of the database memory space and the performance advantage of using stored procedures finally becomes noticeable.

So in general:

• Use ORM for interactive stuff
• Use Stored procedures for non-interactive batch stuff