MyApp.Data.EF4 – Hold reference of MyApp.Common and implements all interfaces using the EF way. It also includes the MyAppModel.edmx that hold model for all the entities in the system. MyAppModel.edmx has Code Generation Strategy set to Default. The entity container name called: MyAppEntities.

MyApp.Domain.Company and MyApp.Domain.Transmission – Contains POCO objects that should hold the query results and be the business logic of the solution. Each project reflects other and different need of the system. But, entities from MyApp.Domain.Company have relationships in the DB and in the edmx with MyApp.Domain.Transmission entities. For example: Vehicle that exists in MyApp.Domain.Company references by VehicleTransmission that exists in MyApp.Domain.Transmission. In addition, VehicleTransmission holds reference of Vehicle and therefore MyApp.Domain.Transmission contains reference of MyApp.Domain.Company. Both projects hold reference to MyApp.Common. It is importent to remember that T_TBL_VEHICLE and T_TBL_VEHICLE_TRANSMISSION (and the connections between them) represented in the same edmx file. Each cs file under those projects contains the POCO entity and a repository manager.

This is actually very similar to my implementation…one major difference is that I didn’t implement the life-cycle management for the UOW. I handle that with dependency injection (Ninject using Request Scope) which produces the same result.

Another major difference in my implementation is that I also have an ObjectContextResolver and anObjectContextFactory. The Unit Of Work and the Repositories use the ObjectContextResolverto gain access to the current Context where the ObjectContextFactory is used by theObjectContextResolver to create new instances of the Context when one does not exist. TheObjectContextFactory also uses an ObjectContextActivationInfo which is a wrapper for the connection string and settings, allowing me to easily vary the way the context is created.

I also have two types of repositories…I have an EntityRepository which is much like your implementation and allows me to query and work with specific entities. I also have aContextRepository which exposes a GetSet<T> method so I can query any entity type in my model.

I also allow my Unit Of Work scope to be a bit more flexible and let the consuming application define the beginning and end of the unit of work. A typical usage looks like this…

This also allows separate Units Of Work to occur with a single Request which is important if some things need to get saved before other things can get created…this happens often when external services or legacy data stores are used in conjunction with EF.

Because I’ve wrapped my code in a using block, once execution is complete, it is automatically disposed.

I also have a Rollback() method on my UnitOfWork that allows changes to be reverted in cases where some code has failed and you don’t want to save the changes.

One limitation of this architecture (both yours and mine) is the inability to perform operations using the UnitOfWork in parallel. I recently had a need to execute two EF queries through my framework in parallel and was not able to do so because the code essentially replaces the current UnitOfWork since my architecture is designed around a single Http Request.