Entity Framework: Providing both DbContext and ObjectContext APIs in shared assembly

Question

I've been constructing a system that will have a central database. Multiple applications will run on top of the database. As such, instead of having to maintain multiple entity framework diagrams and setups, I put all the entity framework classes into one dedicated assembly that will be shared across all the solutions that use the database. So far, this has worked pretty well.

At the moment, I've used entity framework to generated a derived DbContext.

I have found in certain situations, however, that having an object context would have been more convenient for what I was trying to accomplish. One example is a very simple (key->value) caching solution for reference entities. I'm using the name "reference entities" to describe entities that serve little more function than to provide string values, or lookups. In that situation, caching entity objects from DbContexts is troublesome, because you can't simply add them to another DbContext - you have to attach it, if required. (This is an example of the top of my head, so don't worry too much about picking holes in it!).

Therefore, I'm thinking it might be worthwhile providing both a DbContext API and an ObjectContext API in my shared assembly. That way, the users of the assembly can use whichever they decide will be more convenient. Obviously, I will have to split them into two very separate namespaces to avoid class naming collisions, but having a Company.Tech.Database.DBContext namespace and Company.Tech.Database.ObjectContext should be ok, I think.

Does anyone think this is a bad idea? Good idea? My understanding is that although DbContext is newer, it's not necessarily "better" than ObjectContext, it just provides a different API that might be considered simpler, but doesn't that depend on the use case? In which case, wouldn't providing both APIs be a good thing?

Answer 1

You can't say strictly whether a good or bad idea because there is no such thing, it depends totally on your situation. But i could give you a suggestion, you see DbContext wraps an ObjectContext within it and it calls methods on that ObjectContext to do its job, so in way or another it provides a simplified version of the ObjectContext. Of course, this means you can still access the wrapped ObjectContext instance like this var ctx = ((IObjectContextAdapter)db).ObjectContext; where db is your DbContext subclass, so instead of providing two different APIs which may confuse clients and require more maintenance you can enhance you DbContext subclass with the additional methods you require for performance and those additional methods can leverage the ObjectContext. This way you will have less code to maintain and a uniform API.