1

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?

SonOfPirate
  • 5,642
  • 3
  • 41
  • 97

2 Answers2

2

It looks like you haven't done a proper research into EF

If you are using EF 4 you use the CreateObjectSet<T>() method which is similar to the GetTable<T> method

For EF 4.1 there is Set<T>() method

EF 4.1 code first offers mapping similar to NHibernate. It is closer to what fluent nhibernate offers.

Eranga
  • 32,181
  • 5
  • 97
  • 96
  • I've actually read the article you reference and the key here is that the custom DbContext has to be modified each time a new EntityType is added. This is what I want to avoid. I want a single context that can be used for any EntityType (as long as the mapping is defined somewhere). – SonOfPirate Sep 02 '11 at 12:57
  • @SonOfPirate You can use [EntityTypeConfiguration](http://msdn.microsoft.com/en-us/library/gg696117(v=vs.103).aspx) to map entities and load these classes using reflection to avoid modification to the context. Considering the advantages of fluent mappings over external configurations like xml, I wouldn't mind modifying the context to add new entities. – Eranga Sep 02 '11 at 14:26
0

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

Community
  • 1
  • 1
Kirk Broadhurst
  • 27,836
  • 16
  • 104
  • 169
  • Thanks for the links. The last two aren't much help since I already know how to handle the repository and UoW. But, following the link to the "previous post" from the first article did highlight adding new mappings using the EntityConfiguration class which I was not aware of. I will look into that more but am not sure this will fit the bill as it appears to require a new context. I'm hoping to achieve more of a gateway solution where a single context can be used and extended as needed. I'll hafta look into EntityConfiguration more. – SonOfPirate Sep 02 '11 at 13:18