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,486
  • 16
  • 84
  • 135
Lotok
  • 1,759
  • 2
  • 17
  • 27

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?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Is the repository just a layer containing your Models which can be shared by DAL and UI? – Lotok Jun 11 '13 at 18:27
  • 1
    Essentially, yes. It can contain CRUD methods, as well as any other methods that might be deemed useful for one of the higher-level layers. Further reading: http://msdn.microsoft.com/en-us/library/ff649690.aspx – Robert Harvey Jun 11 '13 at 18:30
  • 1
    a "Repository" in an Object Oriented language is usually defined as an interface which your DAL can then implement. By following this pattern you are able to define the return types (model) and interface within your application domain. The DAL would then have to be implemented to satisfy the Repository's contract. – Seth M. Jun 11 '13 at 18:57
  • One thing I thought of Seth, when using Entity framework I take it a repository would be a bit pointless, since your entity models are generated by EF on your DAL regardless. – Lotok Jun 12 '13 at 06:42
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
  • 36,735
  • 6
  • 78
  • 110