2

I was thinking about this earlier today and figured I would get some input on the matter. When I develop applications I would usually have the Data Access Layer on another project, incase it could be re-used elsewhere in a similar manner in the future but also to allow updating the DAL without updating the UI layer.

When doing so I handle all of the data querying etc in the DAL. The application does not need to know if its ADO.NET, EF or a List. However, it occurred to me that in almost all cases the return types are specified in the DAL. So the UI Layer does need to know about types defined there. Is that normal or is there a way for more seperation? (other than using Anon types)

Giorgio
  • 19,764
Lotok
  • 1,809

2 Answers2

2

Complete decoupling is unrealistic; you eventually wind up with grey goo (amorphous data with no shape at all) Data without shape is data without meaning.

Data types are more or less implicitly specified already, due to the data's shape, and EF already abstracts away the underlying data store (although in practice it seldom matters anyway; changing the database vendor once it is chosen is extremely rare), so additional abstraction could be a matter of diminishing returns.

All that said, if you really need additional abstraction, you do it in the usual way: by creating another software layer, like a Repository (which you haven't mentioned yet). Or, you can ditch all that, take the minimalist approach and just use a Key/Value store like BigTable.

See Also
Why is it a good idea for "lower" application layers not to be aware of "higher" ones?

Community
  • 1
Robert Harvey
  • 200,592
1

Yes. This is common problem with many DAL solutions. This is reason why people started using POCO/POJO. This allows you to define entities/objects in one project. And then define database mappings in different project, that references those entities.

First versions of EF didn't allow this. Only latest versions do. NHIbernated (and other 3rd party ORMs) do allow this right from the first versions. You can also create repositories and implementations by yourself. But I would discourage creating your own if you already use some kind of ORM solution, because it will become redundant.

But there are still many problems related to this separation. Even with POCO/POJO, the data access leaks into the base entities. Most common is need to make things public/protected even though they should be private.

Euphoric
  • 38,149