Inversion of Control (IoC) can be quite confusing when it is first encountered.

  1. What is it?
  2. Which problem does it solve?
  3. When is it appropriate to use and when not?

What is Inversion of Control?

I understood, I think, that a &quot;Bean&quot; is a Java-class with properties and getters/setters. &lt;br /&gt;
As much as I understand, it is the equivalent of a C `struct`. Is that true?

Also, is there a real *syntactic* difference between a `JavaBean` and a regular `class`? &lt;br /&gt;
Is there any special definition or an `Interface`?

Basically, why is there a term for this?

Also what does the `Serializable` interface mean? 


What is a JavaBean exactly?

I am currently getting this error:
&gt; System.Data.SqlClient.SqlException: New transaction is not allowed because there are other threads running in the session.

while running this code:

    public class ProductManager : IProductManager
    {
        #region Declare Models
        private RivWorks.Model.Negotiation.RIV_Entities _dbRiv = RivWorks.Model.Stores.RivEntities(AppSettings.RivWorkEntities_connString);
        private RivWorks.Model.NegotiationAutos.RivFeedsEntities _dbFeed = RivWorks.Model.Stores.FeedEntities(AppSettings.FeedAutosEntities_connString);
        #endregion

        public IProduct GetProductById(Guid productId)
        {
            // Do a quick sync of the feeds...
            SyncFeeds();
            ...
            // get a product...
            ...
            return product;
        }

        private void SyncFeeds()
        {
            bool found = false;
            string feedSource = &quot;AUTO&quot;;
            switch (feedSource) // companyFeedDetail.FeedSourceTable.ToUpper())
            {
                case &quot;AUTO&quot;:
                    var clientList = from a in _dbFeed.Client.Include(&quot;Auto&quot;) select a;
                    foreach (RivWorks.Model.NegotiationAutos.Client client in clientList)
                    {
                        var companyFeedDetailList = from a in _dbRiv.AutoNegotiationDetails where a.ClientID == client.ClientID select a;
                        foreach (RivWorks.Model.Negotiation.AutoNegotiationDetails companyFeedDetail in companyFeedDetailList)
                        {
                            if (companyFeedDetail.FeedSourceTable.ToUpper() == &quot;AUTO&quot;)
                            {
                                var company = (from a in _dbRiv.Company.Include(&quot;Product&quot;) where a.CompanyId == companyFeedDetail.CompanyId select a).First();
                                foreach (RivWorks.Model.NegotiationAutos.Auto sourceProduct in client.Auto)
                                {
                                    foreach (RivWorks.Model.Negotiation.Product targetProduct in company.Product)
                                    {
                                        if (targetProduct.alternateProductID == sourceProduct.AutoID)
                                        {
                                            found = true;
                                            break;
                                        }
                                    }
                                    if (!found)
                                    {
                                        var newProduct = new RivWorks.Model.Negotiation.Product();
                                        newProduct.alternateProductID = sourceProduct.AutoID;
                                        newProduct.isFromFeed = true;
                                        newProduct.isDeleted = false;
                                        newProduct.SKU = sourceProduct.StockNumber;
                                        company.Product.Add(newProduct);
                                    }
                                }
                                _dbRiv.SaveChanges();  // ### THIS BREAKS ### //
                            }
                        }
                    }
                    break;
            }
        }
    }

Model #1 - This model sits in a database on our Dev Server.
![Model #1][1] 

Model #2 - This model sits in a database on our Prod Server and is updated each day by automatic feeds.  ![alt text][2]

Note - The red circled items in Model #1 are the fields I use to &quot;map&quot; to Model #2.  Please ignore the red circles in Model #2: that is from another question I had which is now answered.

Note:  I still need to put in an isDeleted check so I can soft delete it from DB1 if it has gone out of our client&#39;s inventory.

All I want to do, with this particular code, is connect a company in DB1 with a client in DB2, get their product list from DB2 and INSERT it in DB1 if it is not already there.  First time through should be a full pull of inventory.  Each time it is run there after nothing should happen unless new inventory came in on the feed over night.

&gt;**So the big question - how to I solve the transaction error I am getting?  Do I need to drop and recreate my context each time through the loops (does not make sense to me)?**


  [1]: http://content.screencast.com/users/Keith.Barrows/folders/Jing/media/bdb2b000-6e60-4af0-a7a1-2bb6b05d8bc1/Model1.png
  [2]: http://content.screencast.com/users/Keith.Barrows/folders/Jing/media/4260259f-bce6-43d5-9d2a-017bd9a980d4/Model2.png

SqlException from Entity Framework - New transaction is not allowed because there are other threads running in the session

According to the [paper written by Martin Fowler][1], inversion of control is the principle where the control flow of a program is inverted: instead of the programmer controlling the flow of a program, the external sources (framework, services, other components) take control of it. It&#39;s like we plug something into something else. He mentioned an example about EJB 2.0:

&gt; For example the Session Bean interface
&gt; defines ejbRemove, ejbPassivate
&gt; (stored to secondary storage), and
&gt; ejbActivate (restored from passive
&gt; state). You don&#39;t get to control when
&gt; these methods are called, just what
&gt; they do. The container calls us, we
&gt; don&#39;t call it.

This leads to the difference between framework and library:

&gt; Inversion of Control is a key part of
&gt; what makes a framework different to a
&gt; library. A library is essentially a
&gt; set of functions that you can call,
&gt; these days usually organized into
&gt; classes. Each call does some work and
&gt; returns control to the client.

I think, the point of view that DI is IOC, means the dependency of an object is inverted: instead of it controlling its own dependencies, life cycle... something else does it for you. But, as you told me about DI by hands, DI is not necessarily IOC. We can still have DI and no IOC.

However, in this paper (from the pococapsule, another IOC Framework for C/C++), it suggests that because of IOC and DI, the IOC containers and DI frameworks are far more superior to J2EE, since J2EE mixes the framework code into the components, thus not making it Plain Old Java/C++ Object (POJO/POCO).

[**Inversion of Control Containers other than the Dependency Injection pattern**](https://web.archive.org/web/20110715101402/http://www.pocomatic.com/docs/whitepapers/ioc-vs-di/) (Archive link)

Additional reading to understand what&#39;s the problem with old Component-Based Development Framework, which leads to the second paper above: [**Why and what of Inversion of Control**](https://web.archive.org/web/20110715095758/http://www.pocomatic.com/docs/whitepapers/ioc/) (Archive link)

**My Question**: What exactly is IOC and DI? I am confused. Based on pococapsule, IOC is something more significant than just inversion of the control between objects or programmers and frameworks.


  [1]: http://martinfowler.com/bliki/InversionOfControl.html

Inversion of Control vs Dependency Injection

I&#39;ve been using [Dependency Injection][1] (DI) for a while, injecting either in a constructor, property, or method.  I&#39;ve never felt a need to use an [Inversion of Control][2] (IoC) container.  However, the more I read, the more pressure I feel from the community to use an IoC container.

I played with .NET containers like [StructureMap](http://docs.structuremap.net), [NInject](http://www.ninject.org), [Unity](http://unity.codeplex.com), and [Funq](http://funq.codeplex.com).  I still fail to see how an IoC container is going to benefit / improve my code.

I&#39;m also afraid to start using a container at work because many of my co-workers will see code which they don&#39;t understand. Many of them may be reluctant to learn new technology.

Please, convince me that I need to use an IoC container.  I&#39;m going to use these arguments when I talk to my fellow developers at work.

  [1]: http://en.wikipedia.org/wiki/Dependency_injection
  [2]: http://en.wikipedia.org/wiki/Inversion_of_control

Why do I need an IoC container as opposed to straightforward DI code?

Which C#/.NET Dependency Injection frameworks are worth looking into?
And what can you say about their complexity and speed.

Which .NET Dependency Injection frameworks are worth looking into?

In Java [IoC][1] / [DI][2] is a very common practice which is extensively used in web applications, nearly all available frameworks and Java EE. On the other hand, there are also lots of big Python web applications, but beside of Zope (which I&#39;ve heard should be really horrible to code) IoC doesn&#39;t seem to be very common in the Python world. (Please name some examples if you think that I&#39;m wrong).

There are of course several clones of popular Java IoC frameworks available for Python, [springpython][3] for example. But none of them seems to get used practically. At least, I&#39;ve never stumpled upon a [Django][4] or [sqlalchemy][5]+`&lt;insert your favorite wsgi toolkit here&gt;` based web application which uses something like that.

In my opinion IoC has reasonable advantages and would make it easy to replace the django-default-user-model for example, but extensive usage of interface classes and IoC in Python looks a bit odd and not &#187;pythonic&#171;. But maybe someone has a better explanation, why IoC isn&#39;t widely used in Python.

  [1]: http://en.wikipedia.org/wiki/Inversion_of_Control
  [2]: http://en.wikipedia.org/wiki/Dependency_Injection
  [3]: http://springpython.webfactional.com/
  [4]: http://www.djangoproject.com/
  [5]: http://www.sqlalchemy.org/

Why is IoC / DI not common in Python?

I find that my constructors are starting to look like this:

    public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )

with ever increasing parameter list. Since &quot;Container&quot; is my dependency injection container, why can&#39;t I just do this:

    public MyClass(Container con)

for every class? What are the downsides? If I do this, it feels like I&#39;m using a glorified static. Please share your thoughts on IoC and Dependency Injection madness.

How to avoid Dependency Injection constructor madness?

I currently creating some experimental projects with nodejs. I have programmed a lot Java EE web applications with Spring and appreciated the ease of dependency injection there.

Now I am curious: How do I do dependency injection with node? Or: Do I even need it? Is there a replacing concept, because the programming style is different? 

I am talking about simple things, like sharing a database connection object, so far, but I have not found a solution that satisfies me.



Do I need dependency injection in NodeJS, or how to deal with ...?

I&#39;m pondering the design of a C# library, that will have several different high level functions. Of course, those high-level functions will be implemented using the [SOLID][1] class design principles as much as possible. As such, there will probably be classes intended for consumers to use directly on a regular basis, and &quot;support classes&quot; that are dependencies of those more common &quot;end user&quot; classes.

The question is, what is the best way to design the library so it is:

 - DI Agnostic - Although adding basic &quot;support&quot; for one or two of the common DI libraries (StructureMap, Ninject, etc) seems reasonable, I want consumers to be able to use the library with any DI framework.
 - Non-DI usable - If a consumer of the library is using no DI, the library should still be as easy to use as possible, reducing the amount of work a user has to do to create all these &quot;unimportant&quot; dependencies just to get to the &quot;real&quot; classes they want to use.

My current thinking is to provide a few &quot;DI registration modules&quot; for the common DI libraries (e.g a StructureMap registry, a Ninject module), and a set or Factory classes that are non-DI and contain the coupling to those few factories.

Thoughts?


  [1]: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Dependency Inject (DI) &quot;friendly&quot; library

What is a good way to explain [dependency injection][1]?

I found several tutorials on Google, but none of them that would assume the reader is just a Java beginner. How would you explain this to a novice?

  [1]: http://en.wikipedia.org/wiki/Dependency_injection


How to explain dependency injection to a 5-year-old?

I&#39;m a long-time Windows developer, having cut my teeth on win32 and early COM.  I&#39;ve been working with .NET since 2001, so I&#39;m pretty fluent in C# and the CLR.  I&#39;d never heard of Castle Windsor until I started participating in Stack Overflow.  I&#39;ve read the Castle Windsor &quot;Getting Started&quot; guide, but it&#39;s not clicking.

Teach this old dog new tricks, and tell me why I should be integrating Castle Windsor into my enterprise apps.

What is Castle Windsor, and why should I care?

I&#39;ve been reading the articles on MSDN about Unity (Dependency Injection, Inversion of Control), but I think I need it explained in simple terms (or simple examples). I&#39;m familiar with the MVPC pattern (we use it here), but I just can&#39;t really grasp this Unity thing yet, and I think it&#39;s the next step in our application design.

Can someone explain Microsoft Unity?

I&#39;m refactoring a class and adding a new dependency to it. The class is currently taking its existing dependencies in the constructor. So for consistency, I add the parameter to the constructor.  
Of course, there are a few subclasses plus even more for unit tests, so now I am playing the game of going around altering all the constructors to match, and it&#39;s taking ages.  
It makes me think that using properties with setters is a better way of getting dependencies. I don&#39;t think injected dependencies should be part of the interface to constructing an instance of a class. You add a dependency and now all your users (subclasses and anyone instantiating you directly) suddenly know about it. That feels like a break of encapsulation.

This doesn&#39;t seem to be the pattern with the existing code here, so I am looking to find out what the general consensus is, pros and cons of constructors versus properties. Is using property setters better?


Dependency injection through constructors or property setters?

I am trying to get Unity to manage the creation of my objects and I want to have some initialization parameters that are not known until run-time:

At the moment the only way I could think of the way to do it is to have an Init method on the interface.

&lt;!-- language-all: c# --&gt;

    interface IMyIntf {
      void Initialize(string runTimeParam);
      string RunTimeParam { get; }
    }

Then to use it (in Unity) I would do this:

    var IMyIntf = unityContainer.Resolve&lt;IMyIntf&gt;();
    IMyIntf.Initialize(&quot;somevalue&quot;);

In this scenario `runTimeParam` param is determined at run-time based on user input. The trivial case here simply returns the value of `runTimeParam` but in reality the parameter will be something like file name and initialize method will do something with the file.

This creates a number of issues, namely that the `Initialize` method is available on the interface and can be called multiple times. Setting a flag in the implementation and throwing exception on repeated call to `Initialize` seems way clunky.

At the point where I resolve my interface I don&#39;t want to know anything about the implementation of `IMyIntf`. What I do want, though, is the knowledge that this interface needs certain one time initialization parameters. Is there a way to somehow annotate(attributes?) the interface with this information and pass those to framework when the object is created?

Edit: Described the interface a bit more.

Is there a pattern for initializing objects created via a DI container

Is it possible to resolve an instance of `IOptions&lt;AppSettings&gt;` from the `ConfigureServices` method in Startup? [The documentation explicitly says][0]:

&gt; Don&#39;t use `IOptions&lt;TOptions&gt;` or `IOptionsMonitor&lt;TOptions&gt;` in `Startup.ConfigureServices.` An inconsistent options state may exist due to the ordering of service registrations.

You can manually create a service provider using `serviceCollection.BuildServiceProvider()` but this results in the warning:

&gt; Calling &#39;BuildServiceProvider&#39; from application code results in an additional copy of singleton services being created. Consider alternatives such as dependency injecting services as parameters to &#39;Configure&#39;.

How can I achieve this?

    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure&lt;AppSettings&gt;(
            configuration.GetConfigurationSection(nameof(AppSettings)));

        // How can I resolve IOptions&lt;AppSettings&gt; here?
    }

  [0]: https://docs.microsoft.com/aspnet/core/fundamentals/configuration/options#accessing-options-during-startup

How to resolve IOptions instance inside ConfigureServices?

What&#39;s pros and cons of using Enterprise Library Unity vs other IoC containers (Windsor, Spring.Net, Autofac ..)?

Enterprise Library Unity vs Other IoC Containers

(Related to this question, https://stackoverflow.com/questions/9500642/ef4-mvc3-with-windsor-castle-ioc-di-navigation-properties-not-loading).

I&#39;m new to DI, so bear with me. I understand that the container is in charge of instantiating all of my registered types but in order to do so it requires a reference to all of the DLLs in my solution and their references.

If I weren&#39;t using a DI container, I wouldn&#39;t have to reference the EntityFramework library in my MVC3 app, only my business layer, which would reference my DAL/Repo layer. 

I know that at the end of the day all DLLs are included in the bin folder but my problem is having to reference it explicitly via &quot;add reference&quot; in VS in order to be able to publish a WAP with all necessary files.

Ioc/DI - Why do I have to reference all layers/assemblies in application&#39;s entry point?

If I understand correctly, the typical mechanism for Dependency Injection is to inject either through a class&#39; constructor or through a public property (member) of the class. 

This exposes the dependency being injected and violates the OOP principle of encapsulation.

Am I correct in identifying this tradeoff? How do you deal with this issue? 


*Please also see my answer to my own question below.*

Must Dependency Injection come at the expense of Encapsulation?

How can a IoC Container be used for unit testing? Is it useful to manage mocks in a huge solution (50+ projects) using IoC? Any experiences? Any C# libraries that work well for using it in unit tests?

Using IoC for Unit Testing

I understand the concept behind DI, but I&#39;m just learning what different IoC containers can do.  It seems that most people advocate using IoC containers to wire up stateless services, but what about using them for stateful objects like entities?

Whether it&#39;s right or wrong, I normally stuff my entities with behavior, even if that behavior requires an outside class.  Example:

    public class Order : IOrder
    {

        private string _ShipAddress;
        private IShipQuoter _ShipQuoter;

        public Order(IOrderData OrderData, IShipQuoter ShipQuoter)
        {
            // OrderData comes from a repository and has the data needed 
            // to construct order
            _ShipAddress = OrderData.ShipAddress;  // etc.
            _ShipQuoter = ShipQuoter;
            
        }

        private decimal GetShippingRate()
        {
            return _ShipQuoter.GetRate(this);
        }
    }

As you can see, the dependencies are Constructor Injected. Now for a couple of questions.

1. Is it considered bad practice to have your entities depend on outside classes such as the ShipQuoter?  Eliminating these dependencies seems to lead me towards an anemic domain, if I understand the definition correctly.

2. Is it bad practice to use an IoC container to resolve these dependencies and construct an entity when needed?  Is it possible to do this?

Thanks for any insight.

Why not use an IoC container to resolve dependencies for entities/business objects?

I am exploring dependency injection and the term **composition root** is used all over the place. So what is it?

What is a composition root in the context of dependency injection?

I&#39;ve started the very long and arduous quest to learn and **apply** TDD to my workflow. I&#39;m under the impression that TDD fits in very well with IoC principles.

After browsing some of TDD tagged questions here in SO, I read it&#39;s a good idea to program against interfaces, not objects.

Can you provide simple code examples of what this is, and how to apply it in real use cases? Simple examples is key for me (and other people wanting to learn) to grasp the concepts.

What do programmers mean when they say, &quot;Code against an interface, not an object.&quot;?

I have been doing SOLID in C# to a pretty extreme level in recent times and at some point realized I&#39;m essentially not doing much else than composing functions nowadays. And after I recently started looking at F# again, I figured that it would probably be the much more appropriate choice of language for much of what I&#39;m doing now, so I&#39;d like to try and port a real world C# project to F# as a proof of concept. I think I could pull off the actual code (in a very un-idiomatic fashion), but I can&#39;t imagine what an architecture would look like that allows me to work in a similarly flexible fashion as in C#.

What I mean by this is that I have lots of small classes and interfaces that I compose using an IoC container, and I also use patterns like Decorator and Composite a lot. This results in an (in my opinion) very flexible and evolvable overall architecture that allows me to easily replace or extend functionality at any point of the application. Depending on how big the required change is, I might only need to write a new implementation of an interface, replace it in the IoC registration and be done. Even if the change is bigger, I can replace parts of the object graph while the rest of the application simply stands as it did before.

Now with F#, I don&#39;t have classes and interfaces (I know I can, but I think that&#39;s beside the point when I want to do actual functional programming), I don&#39;t have constructor injection, and I don&#39;t have IoC containers. I know I can do something like a Decorator pattern using higher order functions, but that doesn&#39;t quite seem to give me the same kind of flexibility and maintainability as classes with constructor injection.


Consider these C# types:

&lt;!-- language: c# --&gt;

    public class Dings
    {
        public string Lol { get; set; }

        public string Rofl { get; set; }
    }

    public interface IGetStuff
    {
        IEnumerable&lt;Dings&gt; For(Guid id);
    }

    public class AsdFilteringGetStuff : IGetStuff
    {
        private readonly IGetStuff _innerGetStuff;

        public AsdFilteringGetStuff(IGetStuff innerGetStuff)
        {
            this._innerGetStuff = innerGetStuff;
        }

        public IEnumerable&lt;Dings&gt; For(Guid id)
        {
            return this._innerGetStuff.For(id).Where(d =&gt; d.Lol == &quot;asd&quot;);
        }
    }

    public class GeneratingGetStuff : IGetStuff
    {
        public IEnumerable&lt;Dings&gt; For(Guid id)
        {
            IEnumerable&lt;Dings&gt; dingse;

            // somehow knows how to create correct dingse for the ID

            return dingse;
        }
    }

I&#39;ll tell my IoC container to resolve `AsdFilteringGetStuff` for `IGetStuff` and `GeneratingGetStuff` for its own dependency with that interface. Now if I need a different filter or remove the filter altogether, I may need the respective implementation of `IGetStuff` and then simply change the IoC registration. As long as the interface stays the same, I don&#39;t need to touch stuff **within** the application. OCP and LSP, enabled by DIP.

Now what do I do in F#?

&lt;!-- language-all: f# --&gt;

	type Dings (lol, rofl) =
	    member x.Lol = lol
	    member x.Rofl = rofl
	
	let GenerateDingse id =
	    // create list
	    
	let AsdFilteredDingse id =
	    GenerateDingse id |&gt; List.filter (fun x -&gt; x.Lol = &quot;asd&quot;)

I love how much less code this is, but I lose flexibility. Yes, I can call `AsdFilteredDingse` or `GenerateDingse` in the same place, because the types are the same - but how do I decide which one to call without hard coding it at the call site? Also, while these two functions are interchangeable, I now cannot replace the generator function inside `AsdFilteredDingse` without changing this function as well. This isn&#39;t very nice.

Next attempt:

	let GenerateDingse id =
	    // create list
	    
	let AsdFilteredDingse (generator : System.Guid -&gt; Dings list) id =
	    generator id |&gt; List.filter (fun x -&gt; x.Lol = &quot;asd&quot;)

Now I have composability by making AsdFilteredDingse a higher order function, but the two functions are not interchangeable anymore. On second thought, they probably shouldn&#39;t be anyway.

What else could I do? I could mimic the &quot;composition root&quot; concept from my C# SOLID in the last file of the F# project. Most files are just collections of functions, then I have some kind of &quot;registry&quot;, which replaces the IoC container, and finally there is one function that I call to actually run the application and that uses functions from the &quot;registry&quot;. In the &quot;registry&quot;, I know I need a function of type (Guid -&gt; Dings list), which I&#39;ll call `GetDingseForId`. This is the one I call, never the individual functions defined earlier.

For the decorator, the definition would be

	let GetDingseForId id = AsdFilteredDingse GenerateDingse

To remove the filter, I&#39;d change that to

	let GetDingseForId id = GenerateDingse

The downside(?) of this is that all functions that use other functions would sensibly have to be higher order functions, and my &quot;registry&quot; would have to map **all** functions that I use, because the actual functions defined earlier can&#39;t call any functions defined later, in particular not those from the &quot;registry&quot;. I might also run into circular dependency issues with the &quot;registry&quot; mappings.


Does any of this make sense? How do you really build an F# application to be maintainable and evolvable (not to mention testable)?

Application architecture/composition in F#

What is the suggested method of getting the Autofac container from inside a class in the application?  Does Autofac provide for resolving an IContainer property on a class or do I need to store the container globally once I&#39;ve build it?

Resolve IContainer

I have the `IRespository` registered twice (with names) in the following code:

    // Setup the Client Repository
    IOC.Container.RegisterType&lt;ClientEntities&gt;(new InjectionConstructor());
    IOC.Container.RegisterType&lt;IRepository, GenericRepository&gt;
        (&quot;Client&quot;, new InjectionConstructor(typeof(ClientEntities)));
    
    // Setup the Customer Repository
    IOC.Container.RegisterType&lt;CustomerEntities&gt;(new InjectionConstructor());
    IOC.Container.RegisterType&lt;IRepository, GenericRepository&gt;
        (&quot;Customer&quot;, new InjectionConstructor(typeof(CustomerEntities)));

    IOC.Container.RegisterType&lt;IClientModel, ClientModel&gt;();
    IOC.Container.RegisterType&lt;ICustomerModel, CustomerModel&gt;();

But then when I want to resolve this (to use the `IRepository`) I have to do a manual resolve like this:

    public ClientModel(IUnityContainer container)
    {
       this.dataAccess = container.Resolve&lt;IRepository&gt;(Client);

       .....
    }

What I would like to do is to have it resolved in the constructor (just like `IUnityContainer`). I need some way to say which named type to resolve to.

Something like this: **(NOTE: Not real code)**

    public ClientModel([NamedDependancy(&quot;Client&quot;)] IRepository dataAccess)
    {
       this.dataAccess = dataAccess;

       .....
    }

Is there a way to make my fake code work?

With Unity how do I inject a named dependency into a constructor?

Looking at Microsoft&#39;s Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other.  More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.  

Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF. 

MEF vs. any IoC

**My understanding:**

* A dependency is when an instance of ClassA requires an instance of ClassB to instantiate a new instance of ClassA.
* A dependency injection is when ClassA is passed an instance of ClassB, either through a parameter in ClassA&#39;s constructor or through a set~DependencyNameHere~(~DependencyNameHere~ $param) function. *(This is one of the areas I&#39;m not completely certain on)*. 
* An IoC container is a singleton Class(can only have 1 instance instantiated at any given time) where the specific way of instantiating objects of those class for this project can be registered. [Here&#39;s a link to an example of what I&#39;m trying to describe along with the class definition for the IoC container I&#39;ve been using](https://gist.github.com/echochamber/021bb0d59f272ac0f421#file-registering-a-mysqli-object)

So at this point is where I start trying use the IoC container for more complicated scenarios. As of now it seems in order to use the IoC container, I am limited to a has-a relationship for pretty much any class I want to create that has dependencies it wants to define in the IoC container. What if I want to create a class that inherits a class, but only if the parent class has been created in a specific way it was registered in the IoC container. 

So for example: I want to create a child class of mysqli, but I want to register this class in the IoC container to only instantiate with the parent class constructed in a way I&#39;ve previously registered in the IoC container. I cannot think of a way to do this without duplicating code (and since this is a learning project  I&#39;m trying to keep it as &#39;pure&#39; as possible). [Here are some more examples of what I am trying to describe.](https://gist.github.com/echochamber/021bb0d59f272ac0f421#file-inheritance-ioc)

**So here are some of my questions:**

* Is what I&#39;m trying to do above possible without breaking some principle of OOP? I know in c++ I could use dynamic memory and a copy constructor to accomplish it, but I haven&#39;t been able to find that sort of functionality in php. (I will admit that I have very little experience using any of the other magic methods besides __construct, but from reading and __clone if I understood correctly, I couldn&#39;t use in the constructor it to make the child class being instantiated a clone of an instance of the parent class).
* Where should all my dependency class definitions go in relation to the IoC? (Should my IoC.php just have a bunch of require_once(&#39;dependencyClassDefinition.php&#39;) at the top? My gut reaction is that there is a better way, but I haven&#39;t come up with one yet)
* What file should I be registering my objects in? Currently doing all the calls to IoC::register() in the IoC.php file after the class definition.
* Do I need to register a dependency in the IoC before I register a class that needs that dependency? Since I&#39;m not invoking the anonymous function until I actually instantiate an object registered in the IoC, I&#39;m guessing not, but its still a concern.
* Is there anything else I&#39;m overlooking that I should be doing or using? I&#39;m trying to take it one step at a time, but I also don&#39;t want to know that my code will be reusable and, most importantly, that somebody who knows nothing about my project can read it and understand it.

Understanding IoC Containers and Dependency Injection

Considering the following interface and class definitions:

    public interface IInterface1 { }
    public interface IInterface2 { }
    public class MyClass : IInterface1, IInterface2 { }

is there any way to register one instance of `MyClass` with multiple interfaces like this:

    ...
    services.AddSingleton&lt;IInterface1, IInterface2, MyClass&gt;();
    ...

and resolve this single instance of `MyClass` with different interfaces like this:

    IInterface1 interface1 = app.ApplicationServices.GetService&lt;IInterface1&gt;();
    IInterface2 interface2 = app.ApplicationServices.GetService&lt;IInterface2&gt;();

Asp.Net Core: register implementation with multiple interfaces and lifestyle Singleton

I&#39;m revamping my software which has messy `Messenger.Default(...)` bits.

Is there any cheat sheet to know MVVMLight SimpleIoc usage (not general IoC description)?

how to use MVVMLight SimpleIoc?

What problems does MEF (Managed Extensibility Framework) solves that cannot be solved by existing IoC/DI containers?

MEF (Managed Extensibility Framework) vs IoC/DI

I am familiar with these patterns but still don&#39;t know how to handle following situation:

    public class CarFactory
    {
         public CarFactory(Dep1,Dep2,Dep3,Dep4,Dep5,Dep6)
         {
         }
    
         public ICar CreateCar(type)
         {
                switch(type)
                {
                   case A:
                       return new Car1(Dep1,Dep2,Dep3);
                   break;
                  
                   case B:
                       return new Car2(Dep4,Dep5,Dep6);
                   break;
                }
         }
    }


In general the problem is with amount of references that needs to be injected. It will be even worse when there are more cars.

First approach that comes to my mind is to inject Car1 and Car2 in factory constructor but it is against factory approach because factory will return always the same object. The second approach is to inject servicelocator but it&#39;s antipattern everywhere. How to solve it?

## Edit: 

Alternative way 1:

    public class CarFactory
    {
         public CarFactory(IContainer container)
         {
            _container = container;
         }
    
         public ICar CreateCar(type)
         {
                switch(type)
                {
                   case A:
                       return _container.Resolve&lt;ICar1&gt;();
                   break;
    
                   case B:
                         return _container.Resolve&lt;ICar2&gt;();
                   break;
                }
         }
    }

Alternative way 2 (too hard to use because of too many of dependencies in tree):

    public class CarFactory
    {
         public CarFactory()
         {
         }
    
         public ICar CreateCar(type)
         {
                switch(type)
                {
                   case A:
                       return new Car1(new Dep1(),new Dep2(new Dep683(),new Dep684()),....)
                   break;
    
                   case B:
                        return new Car2(new Dep4(),new Dep5(new Dep777(),new Dep684()),....)
                   break;
                }
         }
    }

Factory method with DI and IoC

I have a Generic Type Interface and want a constructor of an object to take in the Generic Interface.  
Like:

    public Constructor(int blah, IGenericType&lt;T&gt; instance)
    {}

I want the code that creates this object to specify the IGenericType (use Inversion of Control).  I have not seen a way for this to happen.  Any suggestions to accomplish this?

I want someone to create the object like:

    Constructor varname = new Constructor(1, new GenericType&lt;int&gt;());


Generic Type in constructor

I will have the following components in my application

 - DataAccess
 - DataAccess.Test
 - Business
 - Business.Test
 - Application

I was hoping to use Castle Windsor as IoC to glue the layers together but I am bit uncertain about the design of the gluing.

My question is who should be responsible for registering the objects into Windsor?
I have a couple of ideas;

1.	Each layer can register its own objects. To test the BL, the test bench could register mock classes for the DAL.
2.	Each layer can register the object of its dependencies, e.g. the business layer registers the components of the data access layer. To test the BL, the test bench would have to unload the &quot;real&quot; DAL object and register the mock objects.
3.	The application (or test app) registers all objects of the dependencies.

I am seeking some ideas and pros/cons with the different paths.


Design - Where should objects be registered when using Windsor

I have decided to use IoC principles on a bigger project. However, i would like to get something straight that&#39;s been bothering me for a long time. The conclusion that i have come up with is that an IoC container is an architectural pattern, not a design pattern. In other words, no class should be aware of its presence and the container itself should be used at the application layer to stitch up all components. Essentially, it becomes an option, on top of a well designed object-oriented model.
Having said that, how is it possible to access resolved types without sprinkling IoC containers all over the place (regardless of whether they are abstracted or not)? The only option i see here is to utilize abstract factories which use an IoC container to resolve concrete types. This should be easy enough to swap out for a set of standard factories. Is this a good approach? Has anyone on here used it and how well did it work for you? Is there anything else available?

Thanks!

Abstract factory pattern on top of IoC?

Inspired by a great question (and bunch of great answers) from [here.][1]

Does the statement &quot;Code against an interface, not an object&quot; have any significance in Python?

I&#39;m looking for answers like the ones in the [Original Question][1] but with Python snippets and thoughts.

  [1]: https://stackoverflow.com/questions/4456424/what-do-programmers-mean-when-they-say-code-against-an-interface-not-an-object

All Inversion of-Control Solutions on Gang of Coders

Total of 36 Inversion of-Control Solutions