Just trying to wrap my head around IoC at the moment, and I am part of the way there. An example I found on another post on SO was this:
http://blog.vascooliveira.com/unity-tutorial-and-examples/
The line I don't quite get is this:
ILogger myExampleInstance = myContainer.Resolve(loggerType);
I am not sure what loggerType is as it doesn't mention it anywhere.
I can see that IoC in this case allows us to create a way of writing a log. Rather than instantiate in the code a specific type of logger, we use IoC to create an ILogger interface, and we code to that. This means I assume that we don't care specifically what type of Logger is being used. If we don't care, I am curious to know why we need to pass in a loggerType, or how we know what the loggerType is due to seperation of concerns.
I am half way to understanding it but I just need a final push! =)
What you see there is actually an anti-pattern called Service Locator. The example code directly references the container, calling its Resolve() method.
In 99% of cases you should not ever reference your container within your code - there should only be a single application wide reference to the container at the very highest level of your code. (the final 1% of cases are almost exclusively where a framework you are using doesn't allow dependency injection)
In that single reference to your container you new up objects as needed with all their dependencies injected in a valid state. All your objects receive their dependencies as parameters (most often passing to the constructor).
There are lots of blog posts (here are two I found with some quick googling: Thou Shalt Not Reference The IoC Container and Service Locator Is An Anti Pattern around explaining the various reasons why ServiceLocator is bad.
You have found one example with your question about what loggerType should be, using proper IoC your application should not care - the Service Locator approach tends to mean your application starts to become aware of the details of its dependencies again, which goes against the entire point of using IoC and dependecy injection in the first place.
For further reading on IoC I'd suggest browsing through blog posts by Jeremy Miller, the creater of StructureMap. Don't take that as me saying use StructureMap instead of Unity, but since he wrote a container from scratch most of what he says on the subject is well thought out and he is a good writer.
It would be something like this
public class MyLogger : ILogger
{
//implementation
}
And then
Type loggerType = typeof(MyLogger);
ILogger myExampleInstance = myContainer.Resolve(loggerType);
output = myExampleInstance.MyInterfaceMethod("Unity rocks!");
The problem is, it is actually a ServiceLocator pattern. The DI and IoC would look like this:
public class Foo
{
private ILogger logger;
//This will be injected automatically by IoC
//once you register it somewhere in the app init e.g.
//container.RegisterType<ILogger, MyLogger>();
public Foo(ILogger logger)
{
this.logger = logger;
}
public void Bar()
{
logger.Debug("In the bar");
}
}
While David Hall's answer is more correct, just to answer your question, loggerType is the Type of the logger. In reality, they probably could have done:
ILogger myExampleInstance = myContainer.Resolve(typeof(ILogger));
Or even better, use the generic extension method:
var myExampleInstance = myContainer.Resolve<ILogger>();
The Unity container will look into its list of known mappings, and see what type is mapped from ILogger. It will then create a new instance, and return it.
As a more concise example:
IContainer container = ...;// get or create Unity container
container.RegisterType<ILogger, MyLogger>(); // tell Unity that when I ask for ILogger, I want a MyLogger back
ILogger logger = container.Resolve<ILogger>(); // logger is set to a new instance of MyLogger
I hope that helps!
Related
I'm converting my code to use an IoC Container with StructureMap. Trying to get my head around things, and I feel it's starting to 'click' and I can see how it makes so much sense with the back-end side.
However, I'm working my way down I've spotted a few sitautions where I'm not sure how to make it work. Specifically, the case where my original constructor did something important with an argument that isn't really a dependency, or something that will change at run-time.
Let's say I start with this (pre IoC Container), where I was passing my dependencies using a constructor, but also sending it an ImportantObject that's run-time dependent:
IMyPageViewModel myPageViewModel = new MyPageViewModel(importantObject, dialogManager, pageDisplay, viewModelProvider)
and here it is doing its constructing:
public MyPageViewModel(ImportantObject importantObject, IDialogManager dialogManager,IPageDisplay pageDisplay, IViewModelProvider viewModelProvider)
{
this.dialogManager = dialogManager;
this.pageDisplay = pageDisplay;
this.viewModelProvider = viewModelProvider;
importantObject.DoThatImportantThing();
}
Now, I'm migrating to use the IoC container, and at first I think I should do something like this:
//I need to create an instance to use, so I use my IoC container:
IMyPageViewModel myPageViewModel = container.GetInstance<IMyPageViewModel>();
then letting it resolve it's dependencies, however importantObject is something that's set at runtime. I can't register it as a dependency:
public MyPageViewModel(IDialogManager dialogManager,IPageDisplay pageDisplay, IViewModelProvider viewModelProvider, IContainer container)
{
this.dialogManager = dialogManager;
this.pageDisplay = pageDisplay;
this.viewModelProvider = viewModelProvider;
//however, here I have no access to the important object that I previously passed in my constructor
importantObject.DoThatImportantThing(); //obviously error
}
I thought maybe I should be creating using 'new', and passing the IoC container:
IMyPageViewModel myPageViewModel = new MyPageViewModel(importantObject, container)
then letting it resolve it's dependencies in the constructor:
public MyPageViewModel(ImportantObject importantObject, IContainer container)
{
this.dialogManager = container.GetInstance<IDialogManager>();
this.pageDisplay = container.GetInstance<IPageDisplay>();
this.viewModelProvider = container.GetInstance<IViewModelProvider>();
importantObject.DoThatImportantThing();
}
But that strikes me as not a good idea, specifically, I can't run it with a test register and have it create a dummy/stub "MyPageViewModel" for unit testing.
The only other thing I can think of is to remove all the logic from the constructor and putting it in an initialize method, or property setters. However, this means I have to ensure that initialize is always called before use and it will hide errors/problems.
Are any of these options sensible, how should I manage passing a run-time dependent object in a constructor with Dependency Injection?
I tried to stray away from static factories, as I've read lots about them being anti-pattern/bad practice.
Edit: In response to Bruno Garcia's answer I decided to use a factory type pattern that holds the container and deals with object creation like this:
class PageProvider : IPageProvider
{
public MyPageViewModel GetMyPage(ImportantObject importantObject)
{
//might just get, if it's a single only instance
return MyPageViewModel(ImportantObject importantObject,
container.GetInstance<IDialogManager>(),
container.GetInstance<IPageDisplay>(),
container.GetInstance<IViewModelProvider>())
}
}
StructureMap supports passing arguments to Resolve. This could help you with passing the ImportantObject to the Service you are resolving.
It's worth noting that if you pass your container around, things can get really messy really fast. Avoid using it as a Service Locator.
Ideally you'd use the container to resolve an entry point (e.g: Controller, Consumer worker) and from that point on, there's no direct use of the container anymore. If you need to control the lifetime of the dependencies you are taking into your constructor, there are a number of ways to go about that like:
Taking a Factory or a Func<>.
I suggest you reading carefully the docs of the Container you want to use to understand who controls the lifetime of objects (if a Component implements IDisposable, who's going to dispose it?). When are lifetime scopes created/disposed?
IoC Container's are great but it's very easy to find yourself troubleshooting memory leaks if you don't carefully understand the concept of lifetime ownership.
I'd like to know how to register the classes and setup a Simple Injector container to instantiate the classes in the following way. ie go from manual DI to having the below Consumer class have the CompositeService injected and the object graph and lifetimes setup as follows:
To bring some context (if it helps) the Consumer class might be a ViewModel from a WPF application which gets instantiated when the View is requested.
public class Consumer
{
public Consumer()
{
var sharedSvc = new SharedService();
var productSvc = new ProductService(sharedSvc, new MathHelper());
var compositeSvc = new CompositeService(sharedSvc, productSvc, new MathHelper());
compositeSvc.Process();
}
}
where:
MyContext should be shared within the scope of the calls.
ProductService and CompositeService can be transient or shared within the scope.
MathHelper must be transient.
Q: How can the above be achieved with Simple Injector?
OR more specifically:
How can I instantiate multiple MathHelpers within the context of the Simple Injector Scope?
I've read up on http://simpleinjector.readthedocs.org/en/latest/lifetimes.html
and read and followed the SO answer https://stackoverflow.com/a/29808487/625113 however,
it seems either everything can be transient or scoped but not certain specific objects scoped and the rest transient (which seems odd).
Update 1
The following with Simple Injector will achieve the SharedService result, but if I want ProductService and CompositeService to also have a scoped lifetime it wont work:
cont.RegisterLifetimeScope<SharedService>();
cont.Register<MathHelper>();
cont.Register<ProductService>();
cont.Register<CompositeService>();
using (cont.BeginLifetimeScope())
{
var compositeSvc = cont.GetInstance<CompositeService>();
compositeSvc.Process();
}
If I register either or both of the ProductService or CompositeService as RegisterLifetimeScope I get a Lifetime mismatch exception. ie
cont.RegisterLifetimeScope<SharedService>();
cont.Register<MathHelper>();
cont.RegisterLifetimeScope<ProductService>();
cont.Register<CompositeService>(); // or cont.RegisterLifetimeScope<CompositeService>();
using (cont.BeginLifetimeScope())
{
var compositeSvc = cont.GetInstance<CompositeService>(); // Exception thrown
compositeSvc.Process();
}
Throws an exception leading to this page: https://simpleinjector.readthedocs.org/en/latest/LifestyleMismatches.html
I can under that in relation to Singleton should be dependent on Transient and can infer a sort of understanding that the same could be said in this case that Simple Injector is warning that Scoped can't depend on Transient because Transient isn't managed within the scope.
So my question is more specifically how can I instantiate multiple MathHelpers within the context of the Simple Injector Scope?
Update 2 - Further background and example
Brief background - This situation arose as I have a 4 year old, 2-tier, WPF based application currently using Ninject which has the bloated mixed Service architecture that #Steven describes
in his blog series (ie the Services have become a mash of mixed, semi-related, command and queries). Most of these services are a good candidate for separating out into
ICommandHandler/IQueryHandler architecture...but you can't do things overnight, so first crack was to convert from Ninject to SimpleInjector (yes I know Ninject can do the same thing in regards to this architecture
but there are other reasons for moving to SimpleInjector).
As far as "scoping" the dependency resolution, a "scope" (in this application) is considered to be for the life of a form so one DbContext (like the SharedService in the example above) is shared amoungst the
services that the form/viewModel require and MOST of the services are per scope with some injected services or helper classes needing to be injected as Transient.
This (to me) is analogous to Mark Seemann's hand-coded example from http://blog.ploeh.dk/2014/06/03/compile-time-lifetime-matching/ where he has a Per Request (singleton-scoped) service which has
Transient objects injected into it.
Edit: I had misread Mark Seemann's example and was reading the code as if the BarController were a service. So whilst the BarController object composition is the same the lifetime is not. That said the SomeThreadUnsafeService could just as easily have a new SomeServiceThatMustBeTransient injected into it but, I stand corrected, his example doesn't do this.
Hence I was wanting to know how to do the object composition Mark Seemann does in Simple Injector but outside the context of web reqeusts (my assumption is that Simple Injector's
Per web request scoping is in essence a specific type of Lifetime Scoping).
To address #Steve and #Ric .net's comment and answer, I can see that there is the potential to end up with the scenario where 2 different services use another, shared service that uses a transient object (storing state) and the supposedly transient object becomes a
Singleton Scoped object in the context of "some" of those services. eg
public class SingletonScopedService1
{
private readonly TransientX _transientA;
public SingletonScopedService1(TransientX transientA)
{
_transientA = transientA;
}
public void PokeTransient()
{
_transientA.Poke();
}
}
public class SingletonScopedService2
{
private readonly SingletonScopedService1 _service1;
private readonly TransientX _transientB;
public SingletonScopedService2(SingletonScopedService1 service1, TransientX transientB)
{
_service1 = service1;
_transientB = transientB;
}
public void GoFishing()
{
_service1.PokeTransient();
// This TransientX instance isn't affected
_transientB.Poke();
}
}
public class SingletonService3
{
private readonly SingletonScopedService1 _service1;
public SingletonService3(SingletonScopedService1 service1)
{
_service1 = service1;
}
public void DoSomething()
{
_service1.PokeTransient();
}
}
If DoSomething() is called on SingletonScopedService3 and GoFishing() is called on SingletonScopedService2 (and assuming TransientX maintains state) then results "may" be unexpected depending on the purpose of TransientX.
So I'm happy to accept this since the application is operating as expected (but also accept that the current composition is fragile).
With that said, can my original composition or Mark Seemann's example be registered with Simple Injector with the required life-times or is it strictly not possible by design and better to manually compose the object
graph (or inject a Func as #Ric .net suggests) for the instances where this is required until further refactoring/hardening can be done?
Update 3 - Conclusion
Whilst Ninject allows you to register my original composition like:
var kernel = new StandardKernel();
kernel.Bind<SharedService>().ToSelf().InCallScope();
kernel.Bind<MathHelper>().ToSelf();
kernel.Bind<ProductService>().ToSelf().InCallScope();
kernel.Bind<CompositeService>().ToSelf().InCallScope();
Simple Injector by design does not and I believe my second example is an example as to why.
FYI: In my real-world case, for the few instances that the object graph had this, I've manually constructed the graph (just to get switched to Simple Injector) with the intent on refactoring these potential issues out.
As explained in the linked SO question what the Lifestyle Mismatch exception is basically saying is that you're creating a so called captive dependency when you let a object depend on another object which has a shorter lifestyle.
While it maybe sounds odd to you, a captive dependency is:
A real life problem which, if undetected, would typically lead to very strange bugs which are very hard to debug
A sign, as indicated by Steven, that the service has some kind of state which is never a good sign
If MathHelper has mutable state and therefore needs to be injected in other services as transient, MathHelper has become some sort of 'runtime data'. And injecting runtime data is an anti-pattern.
This blogpost describes in detail what the problem is with runtime data and how to solve this. Solving your problem as described there is the way to go!
Because you did not specify the implementation details of MathHelper, it is hard to give you some advice how you should refactor MathHelper. So the only advice I can give you is, let runtime data or 'state' flow through the system as messages. You can read about message based design here and here.
There are however several other options, which will work but aren't good design IMO. So the advice is not to use these, but to be complete:
Instead of injecting MathHelper as a transient you could inject a MathHelperProvider or even simpler inject a Func<MathHelper> which you could register as singleton:
container.RegisterSingleton<Func<MathHelper>>(() => container.GetInstance<MathHelper>());
Notice that by registering a delegate you will make the container blind. It won't be able to warn you of misconfigurations in this part of the object graph anymore.
The other solutions I had in mind are so ugly in its design, that after writing them, I decided to leave them out of this answer!
If you would add some details about why MathHelper needs to be transient, I could give you some advice where you could make adjustments to make it scoped or even better: singleton.
I think I'm missing a key part of how to actually use IoC/DI. I happen to be using the Unity container. I know how to setup a class to have it's dependencies injected and I also know how to make Unity register a type.
But what I don't know is how to actually then make use of these registrations.
So for example:
var container = new UnityContainer();
container.RegisterType<IRepository, XmlRepository>();
var service = new MyService(container.Resolve<IRepository>());
public interface IRepository
{
void GetStuff();
}
public class XmlRepository : IRepository
{
public void GetStuff()
{
throw new NotImplementedException();
}
}
public class MyService
{
private readonly IRepository _myRepository;
public MyService(IRepository repository)
{
_myRepository = repository;
}
}
Here I have a service layer which accepts a parameter of type IRepository. It's the container part that I seem to not be understanding.
Isn't the point of IoC/DI to be able to not have to manually resolve types every time I need to create an instance? In my code I'm getting the container to resolve a type, unless I'm misunderstanding how this is supposed to work, isn't the container supposed to somehow automatically (with reflection?) inject the dependency I told it to use when I registered the type? var service = new MyService(...) Is calling container.Resolve the correct way of doing this?
I've created a container, but how do I share this container amongst my project/code? This sort of relates to the first question. I had previously thought that there was a single place that you register types. So far the only way I can see how to get around this is to:
Keep registering types wherever I use them and end up with duplicated code
Pass the container around to every place I'm going to be resolving types
Neither of these ways are how I'd expect this to work
Isn't the point of IoC/DI to be able to not have to manually resolve types every time I need to create an instance?
No, that's the point of a DI Container, but there are drawbacks to using a container as well. Favour Pure DI over using a DI Container, as this will teach you how to use Dependency Injection using only first principles.
I've created a container, but how do I share this container amongst my project/code?
You don't. The DI Container should only be used in the Composition Root (if you use a DI Container at all).
Put your container setup in a module that runs when your program starts. You can call it from Main, for example. This is called a boot strapper.
See Dependency Injection with Unity for a good example of how to do this.
You don't need to do new MyService(container.Resolve<IRepository>()). To get an instance of MyService, just use container.Resolve<MyService>(); it will automatically resolves the dependencies for MyService.
I'm just getting started with IoC containers and have picked up Ninject to start with. I understand the principle of the separate modules you can incorporate into a Kernel. But I'm curious if I should have the first line below everywhere in my code where I'm about to ask for the concrete implementation of something from my service layer.
IKernel kernel = new StandardKernel(new SimpleModule());
// example: getting my ContentService
IContentService contentService = kernel.Get<IContentService>();
If I have a class with 10 methods that use the ContentService should I really new up a Module and a Kernel in every method? Seems like a code smell. How do most developers handle this with Ninject? Are there any articles online that show the proper way to do this with the consumer class?
If I have a class with 10 methods that use the ContentService should I
really new up a Module and a Kernel in every method?
No, you should have this class take IContentService as constructor parameter (since it depends on it inside its methods) and then ask the kernel to provide you the instance of this class. Your classes should know nothing about the DI container (Ninject in your case). They should never reference it.
There are, basically two ways of working with IoC: Dependency Injection (DI) and Service Location (SL).
When dealing with dependecy injection, you provide you dependencies from outside your classes. Generally, you do this by injecting (passing) your dependencies into the class constructor or by using setters. For example:
public class SomeClass {
public ISomeDependency SomeDependency {get;set;}
public SomeClass(ISomeOtherDependecy someOtherDependency) {
//...
}
}
In this case, you COULD provide a ISomeDependency implementation through the property and you SHOULD provide ISomeOtherDependecy implementation through the constructor. Ninject support both ways.
The other way of doing (SL) allows you to request for your dependencies in the moment you need, for example:
public void DoSomeAction() {
ISomeDependency someDependency = MyServiceLocatorImpl.GetInstance<ISomeDependence>()
}
If you plan to use the SL approach (or an hybrid one), you could use the Common Service Locator (Ninject has support for it) . It makes easy to switch our IoC engine later.
This is an extension to the question Why do I need an IoC container as opposed to straightforward DI code?
I've been learning Ninject and came up with the following example, the example goes through the manual way of doing DI and the Ninject way of doing DI:
class Program
{
static void Main(string[] args)
{
NinjectWay();
ManualWay();
Console.ReadKey();
}
private static void ManualWay()
{
Console.WriteLine("ManualWay***********************");
IWeapon sword = new Sword();
Samurai samurai = new Samurai(sword);
Console.WriteLine(samurai.Attack("ManualWay..."));
// change weapon
IWeapon dagger = new Dagger();
samurai.Weapon = dagger;
Console.WriteLine(samurai.Attack("ManualWay..."));
IWeapon weapon = new Shuriken();
IWarrior ninja = new Ninja(weapon);
Console.WriteLine("Manual way.. inject shuriken when a ninja. " + ninja.Weapon.Name);
IWarrior ninja2 = new Ninja(weapon);
}
private static void NinjectWay()
{
Console.WriteLine("NinjectWay***********************");
IKernel kernel = new StandardKernel();
kernel.Bind<IWeapon>().To<Sword>();
var samurai = kernel.Get<Samurai>();
Console.WriteLine(samurai.Attack("NinjectWay..."));
kernel.Rebind<IWeapon>().To<Dagger>();
samurai = kernel.Get<Samurai>();
Console.WriteLine(samurai.Attack("NinjectWay..."));
kernel.Bind<IWeapon>().To<Shuriken>().WhenInjectedInto<Ninja>();
var ninja = kernel.Get<Ninja>();
ninja.OffHandWeapon = new ShortSword();
Console.WriteLine("Conditional Injection..."+ninja.Weapon.Name);
Console.WriteLine("Conditional Injection: OffhandWeapon = " + ninja.OffHandWeapon.Name);
var ninja2 = kernel.Get<Ninja>();
Console.WriteLine("Conditional Injection..." + ninja2.Weapon.Name);
Console.WriteLine("Conditional Injection: OffhandWeapon = " + ninja2.OffHandWeapon.Name);
Console.WriteLine("");
}
}
I hear the benefits happen when the scale of the project increases but I'm not seeing it. Help me understand this better. Provide more examples in C#/Ninject and help me understand where the benefits really become apparent.
Unlike the other answers suggest Ninject isn't mainly about making your code more testable. It's Dependency Injection that makes your code more testable! Dependency Injection can be used without an IoC container by creating everything in facotries. But sure, beeing able to replace some parts easily for Integration Tests (don't use Ninject in unit tests) is a nice side effect.
IoC containers like Ninject are mainly about putting your classes together to a working software. In small projects this can easily be done using some factories. But as your application grows the factories get more and more complicated. Imagine an application that has various services some of them are reused others are newly created for every usage. Some of the services are also used by several components.
If you are using a IoC container you have to define exactly once how you get the service instance and what's its lifecycle. On the other hand in a factory you have to specify how you get the instance for every class that needs an instance (e.g. new MyServiceFactory().CreateInstance()). Furthermore, you have to control the lifecycle manually.
This means as the project grows the configuration of an IoC container grows linear together with the project size. But a factory on the other hand grows more exponentional like as there are services that are used throughout the application (e.g. user auth).
BTW: Your example isn't very good because Rebinding isn't a common action. Usually the configuration is done only once at application startup.
GREAT QUESTION!
The BIG BIG win IMHO is when your code that asks for instantiations doesn't know or care what the actual implementations are. This is most evident in mocking - your mocking framework can configure Ninject to return mocked Ninja's, Sword's, and Samarai's that implement behavior your expect in completely different ways.
I have a repositry layer, for example, that depends on IoC to get access to a data-store. For testing, that data-store is a hand-constructed collection of objects. For remote access, the data-store consumes web services. Locally, it's SQL. The repository simply asks for the IDataStore from the IoC and gets whatever was configured to serve up.
Does that help?
One benefit comes in testing.
You can bind Sword to IWeapon in your production code, and FakeSword to IWeapon in your test assembly. This is useful when you need to test something that has a dependency on IWeapon but you don't actually want a real sword.
For example, instead of Sword and IWeapon you have IDataContext and DataContext. Great in your production code when you need to connect to a DB. But for unit tests you probably don't want to actually hit the database for a variety of reasons (performance, inconsistent data etc.) So you'd wire up a FakeDataContext to your IDataContext. Now you've got some control to simulate DB activity for testing.
The main advantage Ninject has over you doing it manually is that somebody else has done a lot of the abstracting for you. Clearly you could reproduce a similar thing by writing similar code to Ninject (something for creating the objects based around interface types), which would allow you to separate your object construction from your object logic but Ninject (and other libraries) have all ready done a lot of the hard work for you so unless you're going to add something new why would you want to create it all again?
The comparison you've got in your question isn't really representative of the way I'd expect Ninject to be used. You're binding and rebinding in the same method that's using the objects. I'd expect the container setup to be done somewhere else. This allows you to change the construction (so that for example it's easier to test by creating mock objects) without altering the code that actually uses the constructed object.