Is a separate Data Layer necessary when using Linq to Entities?

Question

When using Linq to Entities, is it still necessary to abstract database access using a separate Data Layer, or is it acceptable (or even recommended) to make Linq queries directly from code-behind (Since the Get, Add, Update, and Delete functionality is already built into the Entity Framework)?

Answer 1

We use Linq to EF and we still have a separate data layer.

Partly because what happens in the future if we don't want to use EF any more, or if we need to support a database that EF doesn't support. Part of the point of abstraction is that every layer can be changed without effecting the others.

But also because our data layer is a little more complex than just plain loading and saving of data objects. After objects are loaded from EF they are fully disconnected from the EF data context and translated into business objects. The EF generated data objects are never exposed above the data layer. (This is done because of EF's poor support for disconnected client-server applications, so we have to manage that part ourselves)

Answer 2

In my opinion, the Entity framework is a DAL. Although in some applications I have wrapped it because it's still a specific technology and I try abstract specific technologies from the application as a whole. So if there was a need to go to a different one or change how the business objects are created you can do that without affecting the rest of your application.

It's going to be interesting some of the responses you get since this really applies to all OR/M tools.

Answer 3

It depends on how close the dead line is, how big is the application you wish to develop and probably many more.

I would say yes, do implement a data layer. For example: what if the application would need to run using an Oracle database (some time in the future).. things sure would get ugly very quick.

Answer 4

Linq-to-Entities is an implementation detail. A data layer is intended to abstract the implementation away from interactions with the data. This ensures robustness in your system should you discover that Linq-to-entities is not the right fit and you have to change the implementation. Therefore, yes, you still need a data layer.