I have a specific scenario that I am wondering if (and how) Entity Framework might be able to solve.
I am developing the framework for a new solution that will be passed on to many developers to extend and enhance over time. I would like to provide a simple data access layer that they can leverage from the domain layer they are implementing without requiring them to make changes to the data access code. I’m investigating different tools, such as NHibernate, LINQ-to-SQL, EF as well as good old ADO.NET.
As an example of what I’m after, using LINQ-to-SQL, code in the domain layer would call the GetTable<T> method on the L2S DataContext which returns an IQueryable<T>. Theoretically, this means that the DataContext can resolve a request for any T. Of course, in reality, the DataContext has to know how handle T.
Looking at how EF works, I see some parallels to the other tools but can’t quite find how I could accomplish my goals. Here’s what I’d like to have happen:
I provide a default “context” that exposes a method like GetTable<T> (e.g. Query<T>) that returns IQueryable<T>. This allows for future enhancements where T represents EntityTypes that haven’t been implemented yet and makes it easy for developers to focus on the domain layer because all they ever need to do is call GetTable<T> (or similar).
The only other requirement on the domain developer is to provide the mapping layer where the conceptual layer (T) is mapped to the storage layer (the physical database schema).
FWIW, I believe this is easily accomplished with NHibernate via mapping XML files. Is there a way to make this work with EF?
Lots of questions that deal with this same topic. They don’t discuss the pros and cons of EF vs NHiberate etc, but it is very easy to create a very generic data access layer with EF.
http://elegantcode.com/2009/12/15/entity-framework-ef4-generic-repository-and-unit-of-work-prototype/
Generic repository implementation with EF
Entity Framework Generic Repository