Usage of Ioc Containers; Specifically Windsor

Usage of IoC Containers; specifically Windsor

99% of the cases it's one container instance per app. Normally you initialize it in Application_Start (for a web app), like this.

After that, it's really up to the consumer of the container. For example, some frameworks, like Monorail and ASP.NET MVC allow you to intercept the creation of the instances (the controllers in this case), so you just register the controllers and their dependencies in the container and that's it, whenever you get a request the container takes care of injecting each controller with its dependencies. See for example this ASP.NET MVC controller.
In these frameworks, you hardly ever need to call or even reference the container in your classes, which is the recommended usage.

Other frameworks don't let you get in the creation process easily (like Webforms) so you have to resort to hacks like this one, or pull the required dependencies (that is, explicitly calling the container). To pull dependencies, use a static gateway to the container like this one or the one described by maxnk. Note that by doing this, you're actually using the container as a Service Locator, which doesn't decouple things as well as inversion of control. (see difference here and here)

Hope this clears your doubts.

IoC Container Applicability / Scenario Demonstration?

Seems like you want the answer to this question

Obviously if the system is as difficult to setup as you say, then its not going to be worth much when you come to maintaining it. That's a significant thing to bear in mind when using a new technology. Sometimes the old boring stuff is way better because of just this factor.

Castle Windsor uses reflection itself, so its really a wrapper to doing things the way you want anyway. If you can develop a system that is simpler to use than CW then you should, even if it costs you in initial startup time. That cost will be offset by the learning curve of CW in the first place, so it won't be quite like reinventing the wheel.

They do say themselves that IoC is not suitable for small projects,

Also, depending on the size and
complexity of the project, an IoC
container might be overkill. Prefer to
use it on medium to large projects.

Castle.Windsor IoC-container specific configuration

basically what you want to do is something along these lines:

public class WriterFactory : IWriterFactory
{
    public Writer Create(string fileName)
    {
        return new Writer(fileName);
        //if your writers have other dependencies then inject those into the factory via the constructor and use them here
    }
}

then register this factory

container.Register(CastleRegistration.Component.For<IWriterFactory>().ImplementedBy<WriterFactory>());

Then anywhere you need to create a writer take a dependency on the IWriterFactory in the constructor

Castle Windsor are there any downsides?

To answer your questions:

1. That is using reflection and each
   time that an object is called from the
   container, reflection must used so
   performance will be terrible. (Is this
   the case? does it use reflection on
   every call?)

• No, it does not. Most of the time it uses little reflection when you register the component. It may also use reflection while generating proxy type, first time you request a component from the container.

2. If I am relying on Interfaces; how
   do I deal with objects that have extra
   methods and properties which have been
   tacked onto the class? (through
   inheritance)

• It's all a matter of design. You don't want to have each and every object created by the container. You use it primarily for service dependencies. In this case, you don't care about what type is actually hiding behind the interface (that's the whole point of it, isn't it?).

You also can have class components, but they have limitations, and you must be aware of those (for example you can't intercept calls to non-virtual methods). I have found Windsor to be the most mature, and best suited to my style of development container of all.

Other than that, Performance, I haven't heard of a project that had to discard dependency container because of unacceptable performance. Windsor is really smart about it, and it caches the results of lengthy operations so that you don't have to pay the price twice.
You may find charts on the Internet, comparing speed of many IoC containers. Two things to note about those: All containers are really fast.
Don't think that the fact that other containers are faster on these charts than Windsor, means that they are better. Windsor does a lot of stuff for you that other containers don't.

What other IoC containers have an IInitializable like feature?

Autofac can do it - they call it Startable

IoC (Windsor) - What is a Default Interface?

It's a heuristic that looks for an implementation of an interface by removing the leading I:

• IFoo -> Foo
• IBar -> Bar
• IKitchenSink -> KitchenSink

However, in my opinion, using this feature smells of an over-abundance of 1:1 interfaces.

Windsor Ioc container: How to register that certain constructors take different implementation of an interface

Use Service Overrides:

var container = new WindsorContainer();
container.Register(
    Component.For<IMyService>().ImplementedBy<Concrete1>().Named("C1"),
    Component.For<IMyService>().ImplementedBy<Concrete2>().Named("C2"),
    Component.For<ClassA>().ServiceOverrides(ServiceOverride.ForKey("service").Eq("C1")),
    Component.For<ClassB>().ServiceOverrides(ServiceOverride.ForKey("service").Eq("C2"))
);

Windsor Container: How to specify a public property should not be filled by the container?

I created a facility to help with this:

• Castle.Facilities.OptionalPropertyInjection

How to use Windsor IoC in ASP.net Core 2

For others Reference In addition to the solution Nkosi provided.

There is a nuget package called Castle.Windsor.MsDependencyInjection that will provide you with the following method:

WindsorRegistrationHelper.CreateServiceProvider(WindsorContainer,IServiceCollection);

Which's returned type is IServiceProvider and you will not need to create you own wrapper.

So the solution will be like:

public class ServiceResolver{    
    private static WindsorContainer container;
    private static IServiceProvider serviceProvider;

    public ServiceResolver(IServiceCollection services) {
        container = new WindsorContainer();
        //Register your components in container
        //then
        serviceProvider = WindsorRegistrationHelper.CreateServiceProvider(container, services);
    }

    public IServiceProvider GetServiceProvider() {
        return serviceProvider;
    }    
}

and in Startup...

public IServiceProvider ConfigureServices(IServiceCollection services) {
    services.AddMvc();
    // Add other framework services

    // Add custom provider
    var container = new ServiceResolver(services).GetServiceProvider();
    return container;
}

---

Related Topics