Develop Reference

Best practices for Inversion of Control in libraries? [duplicate]

This question already has answers here:
Dependency Inject (DI) "friendly" library
(4 answers)
Closed 5 years ago.
I've been tasked with establishing code patterns to use for new applications that we'll be building. An early decision was made to build our applications and libraries using Prism & MEF with the intent of simplifying testing & reuse of functionality across applications.
As our code base has grown I've run into a problem.
Suppose we have some base library that needs access to some system - let's say a user management system:
public interface IUserManagementSystem
{
IUser AuthenticateUser(string username, string password);
}
// ...
public class SomeClass
{
[ImportingConstructor]
public SomeClass(IUserManagementSystem userSystem){ }
}
We can now create an object of type SomeClass using the ServiceLocator, but ONLY if an implementation of IUserManagementSystem has been registered. There is no way to know (at compile-time) whether creation will succeed or fail, what implementations are needed or other critical information.
This problem becomes even more complicated if we use the ServiceLocator in the library.
Finding the now-hidden dependencies has become a bigger problem than hard-coded dependencies were in legacy applications. The IoC and Dependency Injection patterns aren't new, how are we supposed to manage dependencies once we take that job away from the compiler? Should we avoid using ServiceLocator (or other IoC containers) in library code entirely?
EDIT: I'm specifically wondering how to handle cross-cutting concerns (such as logging, communication and configuration). I've seen some recommendations for building a CCC project (presumably making heavy use of singletons). In other cases (Is the dependency injection a cross-cutting concern?) the recommendation is to use the DI framework throughout the library leading back to the original problem of tracking dependencies.
Dependency Inject (DI) "friendly" library is somewhat relevant in that it explains how to structure code in a manner that can be used with or without a DI framework, but it doesn't address whether or not it makes sense to use DI within a library or how to determine the dependencies a given library requires. The marked answers there provide solid architectural advice about interacting with a DI framework but it doesn't address my question.

You should not be using ServiceLocator or any other DI-framework-specific pieces in your core library. That couples your code to the specific DI framework, and makes it so anyone consuming your library must also add that DI framework as a dependency for their product. Instead, use constructor injection and the various techniques mentioned by Mark Seeman in his excellent answer here.
Then, to help users of your library to get bootstrapped more easily, you can provide separate DI-Container-specific libraries with some basic utility classes that handle most of the standard DI bindings you're expecting people to use, so in many cases they can get started with a single line of code.
The problem of missing dependencies until run-time is a common one when using DI frameworks. The only real way around it is to use "poor-man's DI", where you have a class that actually defines how each type of object gets constructed, so you get a compile-time error if a dependency is introduced that you haven't dealt with.
However, you can often mitigate the problem by checking things as early in the runtime as possible. For example, SimpleInjector has a Validate() method that you can call after all the bindings have been set up, and it'll throw an exception if it can tell that it won't know how to construct dependencies for any of the types that have been registered to it. I also like adding a simple integration test to my testing suite that sets up all the bindings and then tries to construct all of the top-level types in my application (Web API Controllers, e.g.), and fails if it can't do so.

What is the story about NanoContainer in NEventStore?

Is the there a story behind the Nanocontainer Class in NEventStore ?
Is there a relation dependency to other IoC's or is it written from scratch by the author of NEventStore itself ?
I ask this because I like the smart approach of this class, it seem's to be a very lightweight IoC container and very easy to understand.
If there is a unique package with only this functionality it would be fine.

Your question is one that only the developers of NEventStore can truly answer, but from the available source code it is easy to spot that the implementation is very minimalistic and 'lacks' many features that make it a 'real' DI container. As far as I can see, the code is not really based on any existing container, although in basic all containers look alike.
The NanoContainer implementation is meant to implement just enough functionality that NEventStore itself needs or what a user needs when changing the default behavior of the framework.
It's open to discussion what features a DI library should have to be a 'real' DI container, but IMO it should at least be able to auto-wire types (where dependencies are automatically injected into a constructor based on the constructor's arguments). NanoContainer doesn't support this. Other features it lacks are:
Batch-registration features
Registration of open-generic types
Support for (per request) scoped lifestyles.
Unregistered type resolution.
Registration of decorators or interception.
Support for releasing instances (disposing instances when done)
Diagnostic tools to spot common configuration problems
Whether or not you need those features of course depends on a lot of factors.

Writing a library that is dependency-injection "enabled"

I'm working on a project at the moment and it's going to be primarily library-based.
I want the library to be consumed using dependency injection, but I want the library to be largely agnostic towards the container being used.
I wrote a "bridge" library a while back to make this sort of thing easier, but I wasn't sure if this was actually the right approach? (library: https://github.com/clintkpearson/IoCBridge)
I don't want to reference the DI-technology (Ninject, Windsor etc) directly from my library as then it makes it inflexible for people using it.
There are a few other questions on SO in a similar vein but none of them seem to actually address the problem satisfactorily.
As a side note: I realise I could just make sure the library adheres to the general idiom and uses interfaces & ctor arguments for dependencies, and then just leave it up to the consuming app to register the types in the containers.
The only issue I can see with this (and correct me if I'm wrong) is that this requires the consuming app to actually know which types link to which interfaces, whether some need to be registered as singletons etc... and from a plug-and-play usage perspective that's pretty poor.

It's a bit controversial but I suggest using Poor Man's Injection. I'm not saying it's great but it has some valid use cases(just like Service Locator) under some constraints. It will require a little more maintenance but it will save you from depending another libray for IoC container registration. You should read Mark Seemann's article on the subject.
I recently implemented this approach in a very simple library of mine. Basically you write two constructors for the public classes of the library.
internal SitemapProvider(IActionResultFactory actionResultFactory, IBaseUrlProvider baseUrlProvider)
{
_actionResultFactory = actionResultFactory;
_baseUrlProvider = baseUrlProvider;
}
public SitemapProvider() : this(new ActionResultFactory(), new BaseUrlProvider()) { }
As you can see only the second constructor is public and you fill the dependencies yourself. This also provides encapsulation at assembly level. You can still test this class by adding a InternalsVisibleTo attribute to the assembly and use dependency injection in your library freely. The user can also create instances with new keyword or add this class's interface to their IoC registration.
I don't know if there's a widely adopted IoC container registration library in .NET. I thought about writing one myself but each container has their unique features and it gets more complicated with object life cycles. Also people will be uneasy about depending on another library for this.

A good DI implementation should enable DI on any object, regardless of the latter being DI-agnostic or not.
Prism is a bad example, as the last time I used it (2 years ago) it required objects to be DI-agnostic by enforcing use of the [Injection] attribute. A good non-DI-agnostic example is Spring Framework (extremely popular DI framework for Java, has a .NET port called Spring.NET), which allows enabling DI via so-called context files - these are xml files that describe dependencies. The latter need not be part of your library, leaving it as a completely independent dll file.
The example of Spring can tell you that you should not have any specific configuration, prerequisites or patterns to follow in order to make an object injectable, or allow objects to be injected to it, besides the programming to interfaces paradigm, and allowing programmatic access to suitable constructors and property setters.
This does not mean that any DI framework should support manipulation of plain CLR (.NET) objects, a.k.a. POCO-s. Some frameworks rely only on their specific mechanisms and may not be suitable to use with DI-independent code. Usually, they would require direct dependency on the DI framework to the library, which I think you want to (and probably should) avoid.

I think you have slightly misinterpeted the scope of Dependency Injection. DI is a pattern, a subset of IoC, and IoC containers make DI easy and convenient - they assist with dependency resolution. IoC can be categorised as a superset of several methodologies, of which DI is one part.
You do not need IoC frameworks in order to make Dependency Injection work.
If you really insist on using an IoC container instead of leveraging regular DI (i.e. constructor parameters or mandatory property setting) then you should nominate the container/framework, don't try to be all things to all people by trying to kludge together adapters or bridges. Be cautious about over-engineering. A library by its very definition means it has a limited and well defined set of functionality, therefore it should not need a large amount of dependencies injected.
They'll most likely want to implement their own versions of some of the interfaces
You don't need an IoC framework to achieve this. If your constructors have their parameters defined as interfaces then in effect you've already achieved DI - the dependency is injected at construction time and you know nothing about the actual concrete implementation of it. Let the calling code worry about the nitty gritty details of which implementation of that interface it wants to pass in.

What is the use of spring.net?

We are developing an application using Silverlight and WCF Services. Is using Spring.Net is beneficial for us?

>> "Is using Spring.Net is beneficial for us?"
I think the spirit of your question is really geared more towards questioning the benefit of using an IoC/DI framework versus manually managing dependencies as needed. My response will focus more on the why and why not of IoC/DI and not so much on which specific framework to use.
As Martin Fowler mentioned at a recent conference, DI allows you to separate configuration from usage. For me, thinking about DI in the light of configuration and usage as separate concerns is a great way to start asking the right questions. Is there a need for your application to have multiple configurations for your dependencies? Does your app need the ability to modify behavior by configuration? Keep in mind, this means that dependencies are resolved at runtime and typically require an XML configuration file which is nice because changes can be made without requiring a recompile of the assembly. Personally, I'm not a fan of XML-based configuration of dependencies as they end up being consumed as "magic strings". So there's the danger of introducing runtime errors if you end up misspelling a class name, etc. But if you need the ability to configure on-the-fly, this is probably the best solution today.
On the other hand, there are DI frameworks like Ninject and StructureMap that allow fluent in-code dependency definitions. You lose the ability to change definitions on-the-fly, but you get the added benefit of compile time validations, which I prefer. If all you want from a DI framework is to resolve dependencies then you could eliminate XML-based frameworks from the equation.
From a Silverlight perspective, DI can be used in various ways. The most obvious is to define the relationship of Views to ViewModels. Going deeper, however, you can define validation, and RIA context dependencies, etc. Having all of the dependencies defined in a configuration class keeps the code free from needing to know how to get/create instances and instead focus on usage. Don't forget that the container can manage the lifetime of each object instance based on your config. So if you need to share an instance of a type (e.g. Singleton, ManagedThread, etc.), this is supported by declaring the lifetime scope of each type registered with the container.
I just realized at this point I'm ranting and I apologize. Hope this helps!

Personally i'd recommend using either Castle or Unity as i've had great success with both and found them both, while different, excellent IOC frameworks.
Besides the IOC component they also provide other nifty tools (AOP in Castle, Interface interception in Unity, for example) which you will no doubt find a use for in the future, and having an IOC framework in place from the start is ALWAYS a hell of a lot easier than trying to retrofit it.
It's incredibly easy to setup and configure, although personally i'm not a huge fan of the XML config way of doing things as some of those config files can turn into a total nightmare. A lot of people will tell you that it's only worth doing if you intend to swap components in and out, but why not just do that anyway IN CASE you decide you need to do that later. it's better to have it and not use it, than not have it and need it. If you're worried about perf hit i've seen on many blog posts around the web people comparing the various IOC frameworks for their speed and unless you're creating brain surgery robots or the US Missile defence platform it won't be an issue.

A DI Framework might be of use if you want to change big chunks of your application without having to rewrite your constructors. For example, you might want to use a comet streaming service that you will expose through an interface, and later decide that you'd rather use a dedicated messenging system such as MQ or RendezVous. You will then write an adapter to Mq that respects the common facade and just change the spring config to use the Mq implementation rather than the Comet one.
But for the love of tony the pony, don't use Spring.Net to create your MVVM/MVP/MVC bindings for each and every view or you'll enter a world of pain.
DI is a great tool when used with parcimony, please don't end-up with 243 spring configuration files, for your devs' sanity.

Using an IOC container such as Spring.Net is beneficial as it will enable you to unit test parts of your UI by swapping in mocked or special test implementations of the applications interfaces. In the long run, this should make your application more maintainable for future developers.

I think if you do more in the code rather than using the markup to do bindings etc. and have a BAL/DAL DI can help there because it can inject the correct business component reference (as one example). DI has many other practical advantages, but then you have to do more in code and less in markup.

When would you use the Common Service Locator?

I've been looking at the Common Service Locator as a way of abstracting my IoC container but I've been noticing that some people are strongly against this type of this.
Do people recommend never using it? Always using it? or sometimes using it?
If sometimes, then in what situations would you use it and what situations would you not use it.

Imagine you are writing library code to be used by 3rd party developers. Your code needs to be able to create service objects that these developers provide. However you don’t know which IoC container each of your callers will be using.
The Common Service Locator lets you cope with the above without forcing a given IoC on your users.
Within your library itself you may wish to register your own classes in the IoC, now it gets a lot harder as you need to choose a IoC for your own use that will not get in the way of your callers.

I noticed that one of the arguments against using the CSL is a false one, because developers think this library is only capable of doing the Service Locator pattern. This however isn't the case, because it is easy to use it with the Dependency Injection pattern as well.
However, the CSL library was specially designed for framework designers who need to allows users to register dependencies. Because the library will be calling the CSL directly, from the framework's perspective we're talking about the SL pattern, hence its name.
As a framework designer however, taking a dependency on the CSL shouldn't be taking lightly. For usability of your framework it is normally much better to have your own DI mechanism. A very common mechanism is to set up dependencies in the configuration file. This pattern is used throughout the whole .NET framework. Almost every dependency can be replaced for another. The .NET provider pattern is built on top of this.
When you, as a framework designer, take a dependency on the CSL, it will be harder for users to use your application. Users will have to configure an IoC container and hook it up to the CSL. However, it is not possible for the framework to validate the configuration as can be done while using the .NET configuration system, which as all kind of validation support in it.

I've done some reading on the service locator concept lately. It is a way of helping to reduce coupling, but requires code coupling to the locator - not the container backing the locator, but the locator itself. It is a tradeoff, but can be beneficial in the right situation.
One situation where it can be helpful is when you have code that does not make use of DI, such as legacy code - I am in this boat now. Pulling in required objects via SL, rather than directly creating them, allows the addition of some abstraction. I see it as an intermediate step between SL and DI/IoC.

If you have library code that is in need of services and this code could be hosted in the context of a larger framework/runtime then the framework / runtime would need to provide a mechanism where you can run some custom code on startup wherein you can initialize your container and register dependencies.
A good example of where CSL can be problematic is when using it in the context of MSCRM. You can have custom business logic executed by registering plugins which the MSCRM framework executes on certain events. The problem you run into is where do you run the registration logic since there is no "startup" event that you can subscribe to for setting up your DI container. Even if you could somehow setup your DI you would need to put the CSL and the DI libraries in the GAC since that is the only way to call out to 3rd party code from a plugin (one more item to add to your deployment checklist).
In scenarios such as this you are better off having your dependencies as constructor parameters that the calling code can initialize as it sees fit( via either constructor injection or manually "newing" up the appropriate interface implementation).