inversion-of-control

I'd like to configure the Windsor container so that a single, singleton-style instance can provide two or more services through the container. I've found that using the same type in multiple component declarations (XML-based config) will result in an instance of that type being created to provide each component's service interface, which is not the behaviour I desire. For example: interface IA { } interface IB { } class AB : IA, IB { ... } I want the one instance of AB to provide both the IA and IB services. The specific reason I want to do this is that my concrete DAO implementation extends

I am brand new to IoC and thus have been following the examples provided by Jeffery Palermo in his posts at http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ and in his book hosted here https://github.com/jeffreypalermo/mvc2inaction/tree/master/manuscript/Chapter23 Most important to note is that I am not using a pre-rolled IoC container, mostly because I want to understand all the moving parts. However, I am creating a windows service rather than an ASP.NET MVC webapp so I am little bogged down on the startup portion. Specifically, in the web.config he registers an IHttpModule

I'm getting the 'No parameterless constructor defined for this object' on my controller when the controller and its dependencies are being registered accordingly via (DI/IoC) pattern using Castle Windsor. Can someone take a look at the following and see my error because i can't see it. Code for registration on global.asax public class MyApplication : System.Web.HttpApplication { public MvcApplication() { this.container = new WindsorContainer().Install(new DependencyInstaller()); } protected void Application_Start() { AreaRegistration.RegisterAllAreas(); WebApiConfig.Register

I am trying to implement DI using Autofac IOC in Azure function. I need to build the container, but not sure where to put the code to build the container I think for now you would need to do something ugly like: public static string MyAwesomeFunction(string message) { if (MyService == null) { var instantiator = Initialize(); MyService = instantiator.Resolve<IService>(); } return MyService.Hello(message); } private static IService MyService = null; private static IContainer Initialize() { // Do your IoC magic here } I did write a blog entry for doing dependency injection with Autofac in Azure

How do you determine which classes should be constructed through an IOC container, and which ones shouldn't. I've worked on projects with both extremes and it seems like interfaces should only be used when the classs specifies a specific technoliogy like logging or data access? Where do people draw the line between the two? I don't draw any line - the more, the merrier. What happens is that the more you can manage to split up your API in small units, the closer you get to the Single Responsibility Principle , because everything that hides behind an interface will have a tendency to do only one

Possible Duplicate: Which .NET Dependency Injection frameworks are worth looking into? Which is the best IoC among StructureMap and Ninject? This should be merged with: Best injections frameworks Depends on the situation. For small projects where you need a simple container I'd choose Ninject. I like the fact that it's small and lean. I dislike the attribute's but there are ways around that. For a big solution where you might need more than simple IoC i'd go with the Castle stuff. Lot's of flexibility there, you can use xml, attributes or a DSL to configure stuff, you can expand your IoC into

We are evaluating IoC containers for C# projects, and both Unity and Castle.Windsor are standing out. One thing that I like about Unity (NInject and StructureMap also do this) is that types where it is obvious how to construct them do not have to be registered with the IoC Container. Is there way to do this in Castle.Windsor? Am I being fair to Castle.Windsor to say that it does not do this? Is there a design reason to deliberately not do this, or is it an oversight, or just not seen as important or useful? I am aware of container.Register(AllTypes... in Windsor but that's not quite the same

I have recently started to use DI in one of my projects. For runtime dependent classes, I created corresponding Abstract factories. After following this pattern I end up having too many abstract factories, almost one for each of my class. Is it common to end up having too many abstract factories when using IOC ? Scenario: Suppose I get an "Entity" object from a database. There are 10 different use cases a user could perform on this entity object. For each of the usecase I have a different class to handle it. In some cases a given use case could have sub use case components which may also need