C# Dependency Injection MVVM – Should IoC Container Be Part of Portable Library

cdependency-injectioninversion-of-controlmvvmportability

I am seeing the benefits of Portable Class Libraries for centralizing Models and ViewModels to a single code-base. Where should dependency injection management (IoC container) take place, though? My Models have dependencies that I believe would benefit from being supplied through injection. I'm not sure how to go about "bootstrapping" to set up the container in the portable library, and I also saw some suggestions that a portable library shouldn't have a dependency on a DI framework. Those points have me thinking maybe the DI should be set up in the applications that use my portable library. This seems rather backwards though, requiring someone using the library to add the bootstrapping portion to their application, as well as it would be duplicated in every app that uses the library. Should the library or the application handle DI?

Some specifics on what my environment in question is like: c#, WPF application referencing PCL with Models, ViewModels and core logic. Considering using Autofac for my IoC container.

Best Answer

If you need IoC in your library then it may be helpful to provide hooks so a user can use the same containers, but don't require it as the developer may want to use something else.

So make it available since you will include it, but don't limit the programmer's options, if possible.

Related Solutions

Dependency Injection – Acceptable Placement of Composition Root Using DI and IoC Containers

Your binding module approach is the best solution. If the client is unlikely to change the configuration, the use of DI is questionable, for your library specifically.

If you wish to create a library for release to the public, you probably don't want clients to deal with the complexity or rigidity of the particular DI system you favor at the moment. Libraries are best when they are lower level components that can be used without lots of dependencies, or extensive training. Any DI system you select will change over time, and may become incompatible with client applications.

Dependency Injection – Abstract Factory Patterns in C#

It seems you're struggling trying to create objects that create objects... wouldn't you be better off just creating objects ?

Ninject allows you to do so in a very simple way :

// Ninject module
Bind<IRepository<SomeEntity>>().To<SomeEntityRepository>();

// injected class
public class SomeService
{
  public SomeService(IRepository<SomeEntity> repository)
  {
    // ...
  }
}

// get instance of injected class
var someService = kernel.Get<SomeService>();

I can't see the benefit of an abstract factory in addition to an IoC container when you're creating objects based on basic, compile-time-known constraints such as in your SomeViewFactory and SomeRepositoryFactory examples.

The dynamic nature of SomeFunctionalityFactory would be more debatable, but when you think of it, do you really need to instantiate an object with the built-in notion that it will never be able to be used by the current user ? Wouldn't it make more sense to have the object evaluate user authorization when the functionality is called ?

Related Topic