1

I am looking to do the equivalent of this:

DependencyResolver.SetResolver(new SimpleInjectorDependencyResolver(container));

But in a console application. I also have cases where I need to do this in a worker role. I don't want to have to add a reference to the MVC dll all over the place. I am wondering if there is an equivalent for non-mvc projects? I need to stash the container I create so I can access it throughout my application. I thought of creating a static variable, but I'd rather not do this.

I saw there is a CommonSerivceLocator nuget for Simple Injector but oddly it requires 2.8.1 and the latest non-mvc Simple Injector is 2.8.0.

KingOfHypocrites
  • 9,316
  • 9
  • 47
  • 69

1 Answers1

2

I don't want to have to add a reference to the MVC dll all over the place.

This indicates that you are not applying dependency injection but are doing Service Location, which is an anti-pattern.

If you apply constructor injection to all your components, you will be able to let Simple Injector build up a complete object graph of dependent components (of many levels deep) without any of your components to know about the existence of an IoC container such as Simple Injector or an IoC abstraction such as the Common Service Locator and MVC's IDependencyResolver. This prevents you from referencing your IoC container or such abstraction "all over the place".

So in a Console Application that means that you typically have one place where you resolve the object graph(s). This is the place in the application that already knows about the existence of the IoC container. This place is typically referred to as the Composition Root.

I saw there is a CommonSerivceLocator nuget for Simple Injector but oddly it requires 2.8.1 and the latest non-mvc Simple Injector is 2.8.0.

I seem to have made an error in the build scripts that create the NuGet packages and although NuGet usually applies checks when a package is uploaded, for some reason it failed to check this. I fixed this and pushed v2.8.2 of the CommonServiceLocator adapter to NuGet. But note that we are dropping support for the CSL adapter in v3 of Simple Injector because it leads to bad practice. Don't use it; you don't need it.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • Thanks! I'm not sure how not wanting to reference the mvc dll has anything to do with whether I'm using dependency injection or not, but I see your point and it's true that I'm not trying to use dependency injection everywhere just yet. Honestly I'm not a fan of using DI in anything but huge projects, but ironically my MVC layer is what got my thinking about how I'm going to have problems passing around the objects I am creating from my starting point. I just wanted to have SimpleInjector manage a few Singletons for me and maybe ease my way into using injection for everything a bit later. – KingOfHypocrites Jun 27 '15 at 13:36
  • I started with a few of my other non-mvc projects and that's what brought me to the resolver question. I'm assuming you are the developer of this module based on your answer, so Kudos. My brief reading showed it to be the fastest component out there. – KingOfHypocrites Jun 27 '15 at 13:38
  • 1
    I spent the day refactoring my code to use injection from the starting point and it's working beautifully. I am often an opponent of needlessly implementing injection and use of interfaces for every concrete class, but I am starting to see even for smaller apps DI solves a lot of issues. I've seen it greatly misused in some projects, but I am becoming a believer again. Great product btw. – KingOfHypocrites Jun 27 '15 at 23:40