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)
Separation of Concerns, Data Access Layer
object oriented;data structures
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 AlsoWhy is it a good idea for lower application layers not to be aware of higher ones?