Resolving Unity Dependencies without a Unity.MVC

Question

I have two projects that use the following Unity logic:

container.RegisterType<IUnitOfWork, MyDbContext>(
    new HierarchicalLifetimeManager(),
    new InjectionFactory(
        c => new MyDbContext(configurationService.MySqlConnectionString)
    )
);
container.RegisterType<DbContext, MyDbContext>(
    new HierarchicalLifetimeManager()
);

The first project is a web application that utilises the Unity.MVC4 package so has a bespoke DependencyResolver doing some of the work - this works perfectly .

The second is a non-web application so uses a normal Unity package instance but errors when a call is made that uses MyDbContext . The exception is

System.Data.Entity.Core.MetadataException: Schema specified is not valid. Errors: EntityDataModel.MyProject.ssdl(2,2) : error 0152: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' for the 'System.Data.SqlClient' ADO.NET provider could not be loaded. Make sure the provider assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.

I've setup both projects to call the same service , which is in a separate project, in an attempt to isolate the source of the problem to the second project's Unity logic. I should also note I'm using Entity Framework 6 as the ORM.

My question is what Unity code do I need to get the second project to work, or is there some app.config entry I can add to reference the EF assemblies?

Update: After some additional work I noticed that if I reference the DbContext assemblies:

• EntityFramework
• EntityFramework.SqlServer

in the second projects the problem disappears. I want to avoid referencing these assemblies because my client projects shouldn't have any knowledge of the ORM.

I've also tried updating the connection string so I'm manually specifying the ORM project's assembly (where my EDMX file is) as mentioned in this StackOverflow question but that hasn't made any difference.

metadata=res://nameOfDll/Model.csdl|res://nameOfDll/Model.ssdl|res://nameOfDll/Model.msl

Answer 1

You're doing it in the right way.

With DI you can remove dependencies from your application. So that you can get a "Repository agnostic" application. And you have effectively done it. At least on the projects that 'declare' the dependencies.

However, when the application has to run, you need to specify the concrete objects which will be used for the "declared" abstract dependencies (interface, abstract class) is required.

You do this by registering the types which object will be used for each abstract dependency. In you sample, when a IUnitOfWork or a DbContext , an instance of MyDbContext is provided.

So the projects that 'declare' the dependencies are completely independent of a particular implementation.

However, when you register the dependent types, you're loosing that independence.

Let's see it with an example:

If I say "I'm thirsty, I need to drink but I don't mind what I drink", I'm dependent on any drink, not on a particular one. But If I say "When I'm thirsty I want to drink coke" I'm dependent on coke.

The first part is the abstract definition of the dependency: "any drink" (like the abstract IUnitOfWork or DbContext ). And the second part is the concrete dependency: "coke" (like MyDbContext ).

So, I'm independent from coke as long as I don't specify that's what I want to drink. But once I say it, I'm dependent.

Perhaps what you're looking for is a way to change the repository at runtime. You can do it: don't register the dependencies in your code, because you need to make a reference to the project with the chosen concrete types. Do it in an external configuration (ie a file), so that you can compile your project without reference to the dependencies, and provide the required assemblies at runtime.

NOTE: When I say "declare" I mean using any of the patterns for injecting dependencies, like constructor injection (most advisabke) or any other injection pattern (property dependencies).