Hi I just started learning how to use an IOC Container. I picked Autofac and was registering services to inject into my MVC controllers.
Now I want to do Unit Test. I know that moq is to mock up dependencies that my controller needs. But then what is AutoFac's AutoMock for? What advantage would I have?
I noticed that the containerbuilder from AutoMock.GetLoose() has no knowledge of the registrations from the main project.
It is basically just a wrapper for Moq that automatically helps you creating the class you want to test and will inject all required mock-instances into that class.
It makes unit-testing easier because whenever you add another dependency to the constructor of the class under test, you basically don't have to manually create another mock. You will only need to setup behavior, if required.
The documentation is quite good, I'd advice you to look into that.
Related
I'm building a new asp.net webapi application that may use asp.net MVC controllers later.
I'm going to use Unity as an IOC + Lifetime resolver to handle my objects.
I want all my types to be resolved in one place.
I've read about the IDependencyResolver which provides a service-locator(I know it's an anti-pattern) and it seems to fit my goals.
I've tried to find the "scope" of this IDependencyResolver and couldn't.
What I did see is that's he's under System.Web.Mvc - that kinda made me think about his "scope".
When does he "start" his job in the asp.net application lifecycle?
Will he resolve HttpModules as well? Or does he "kick in"
My Global.asax code will look something like this:
ApplicationUnityResolver resolver = new ApplicationUnityResolver(ApplicationContainer._container, DependencyResolver.Current);
GlobalConfiguration.Configuration.DependencyResolver = resolver;
DependencyResolver.SetResolver(resolver);
My ApplicationUnityResolver is:
System.Web.Mvc.IDependencyResolver and System.Web.Http.Dependencies.IDependencyResolver
I think it is fairly early in the MVC pipeline the DependencyResolver get instantiated. MVC framework internally use the DependencyResolver. As you know the DependencyResolver finds and create instance of Controllers, during the Controller creation. Which is right after the IRouteHandler i.e MvcRouteHandler get invoked - fairly early in the life cycle.
But it is well after the HttpModules get created, I think you are out of luck using the DependencyResolver to register HttpModules.
I don't think you cannot customize the scope of the IDependencyResolver. It is just Service Locator type container which helps you to plugin your own dependency resolution mechanism.
Yes IDependencyResolver is an anti-pattern and I personally don't like it. Actually
Mark Seemann has a really good article on the IDependencyResolver. I'm sure this would point you to the right direction.
You better off using the Composition Root pattern to register dependencies in a single location.
I have been working alot on MVC3 now a days and use Dependency Injection ninject etc.
I find it useful in Testing, don't make concrete implementation of classes like Model but instead injected.
My Questions:
How do we explain DI. Any simple definition to it.?
The benefits of DI?
Can we use DI in ASP.NET web forms?
Thanks
Dependency injection is eliminating the objects dependencies of concrete classes.
Benefits:
It allowed to use an abstract interface instead of a concrete class.
This makes lots of (large) applications to be more manageable, if you need to swap out a class, its easier to inherit from an interface and make the IoC container switch to another class.
And if you're looking to use DI in ASP.NET Web Forms in the business logic, yes you can.
Dependency injection means giving an object its instance variables.
Here is a great article about it:
http://jamesshore.com/Blog/Dependency-Injection-Demystified.html.
Can't be simplier, I think.
Benefits: Loose coupling. Easy implementation changes by just editing config file. Easy testing with mocks.
In WebForms? Sure, I've been working on a project where we successfully used Castle Windsor to inject our Repositories.
Brad Wilson has a really good ASP.NET MVC 3 Service Location blog series. It may help you see the value.
I am trying to mock UnityContainer for writing test harness in an asp.net mvc 2 application.
are there any examples available ?
Thanks
Simple Answer: Don't. The container should be invisible to your controllers or anything else you need to test. If it is leaking into your code then you're probably using it incorrectly and should think about redesigning your code.
That said, if you really, really need to then reference the UnityContainerBase abstract class in your code instead of the UnityContainer class itself. You'll still be able to pass in the normal UnityContainer object when your application is running, but you'll also be able to get RhinoMocks to generate a mock of UnityContainerBase to pass in when you are running unit tests.
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.
I want to isolate all my code from the IoC container library that I have chosen (Unity). To do so, I created an IContainer interface that exposes Register() and Resolve(). I created a class called UnityContainerAdapter that implements IContainer and that wraps the real container. So only the assembly where UnityContainerAdapter is defined knows about the Unity library.
I have a leak in my isolation thought. Unity searches for attributes on a type's members to know where to inject the dependencies. Most IoC libraries I have seen also support that. The problem I have is that I want to use that feature but I don’t want my classes to have a dependency on the Unity specific attribute.
Do you have any suggestions on how to resolve this issue?
Ideally I would create my own [Dependency] attribute and use that one in my code. But I would need to tell the real container the search for my attribute instead of its own.
Check out the Common Service Locator project:
The Common Service Locator library
contains a shared interface for
service location which application and
framework developers can reference.
The library provides an abstraction
over IoC containers and service
locators. Using the library allows an
application to indirectly access the
capabilities without relying on hard
references. The hope is that using
this library, third-party applications
and frameworks can begin to leverage
IoC/Service Location without tying
themselves down to a specific
implementation.
Edit: This doesn't appear to solve your desire to use attribute-based declaration of dependency injection. You can either choose not to use it, or find a way to abstract the attributes to multiple injection libraries (like you mentioned).
That is the basic problem with declarative interfaces -- they are tied to a particular implementation.
Personally, I stick to constructor injection so I don't run into this issue.
I found the answer: Unity uses an extension to configure what they call "selector policies". To replace the attributes used by Unity, you just code your own version of the UnityDefaultStrategiesExtension class and register you own "selector policies" that use your own attributes.
See this post on the Unity codeplex site for details on how to do that.
I'm not sure that it's going to be easy to do the same if I switch to another IoC library but that solves my problem for now.
Couldn´t you just setup your configuration without the attributes, in xml. That makes it a bit more "unclear" I know, personally I use a combination of xml and attributes, but at least it "solves" your dependency on unity thing.