The composition root is the single place in your application where the composition of the object graphs for your application take place, using the dependency injection container (although how this is done is irrelevant, it could be using a container or could be done manually using [pure DI](http://blog.ploeh.dk/2014/06/10/pure-di/)).

There should only be one place where this happens and your container should not need to be used outside of the composition root.

Quoting from one of the answers linked to below:

&gt; In practice, this means that you
&gt; should configure the container at the
&gt; root of your application.
&gt; 
&gt;  - In a desktop app, that would be in the Main method (or very close to it)
&gt;  - In an ASP.NET (including MVC) application, that would be in
&gt; Global.asax
&gt;  - In WCF, that would be in a ServiceHostFactory
&gt;  - etc.

There is a good answer [here](https://stackoverflow.com/questions/1410719/design-where-should-objects-be-registered-when-using-windsor/1410738#1410738)  which explains a bit more about this.

See also [this answer](https://stackoverflow.com/questions/1475575/where-should-i-do-dependency-injection-with-ninject-2/1475861#1475861).

Mark Seemann wrote a great article about Composition Root design pattern.

essential points from this article are:

&gt; A Composition Root is a (preferably) unique location in an application
&gt; where modules are composed together.


&gt; Only applications should have Composition Roots. Libraries and
&gt; frameworks shouldn&#39;t.


&gt; A DI Container should only be referenced from the Composition Root.
&gt; All other modules should have no reference to the container.


http://blog.ploeh.dk/2011/07/28/CompositionRoot/

I wrote my own JavaScript Dependency Injection Framework called Di-Ninja with these principles in mind

https://github.com/di-ninja/di-ninja

As I know, is the only one in javascript that implement the Composition-Root design pattern
and it&#39;s documentation could be another good example to demonstrate how it works.

It work with NodeJS, browser (with Webpack or UMD/AMD), and React-Native.

I wold like to disable particular warnings for all files that are included, directly or indirectly, by particular include files. For example, I want to disable the warning &quot;you are assigning a string literal to a char*&quot;, for all files or files included by files included by a `#include &lt;bar/*&gt;` (the star in my case means &quot;anything may be here&quot;). 

The reason is, some of the people I have to program with just can&#39;t use &quot;const&quot;, so in the end I get lots of warnings about that particular string literal abuse. I would like to ignore those thousands of warnings coming from their code, so I can concentrate on the mistakes in my own code and fix them. 

I use Intel C++ and GCC. Some of my buddies use clang, so I would be glad to hear solutions for that too. 

How to disable warnings for particular include files?

I&#39;m having some troubles understanding how OAUTH-v2 works.

The [OAuth version 2 spec][1] reads:

&gt; 7. Accessing Protected Resources
&gt; 
&gt; 
&gt;    The client accesses protected
&gt; resources by presenting the access   
&gt; token to the resource server.  The
&gt; resource server MUST validate the   
&gt; access token and ensure it has not
&gt; expired and that its scope covers   
&gt; the requested resource.  The methods
&gt; used by the resource server to   
&gt; validate the access token (as well as
&gt; any error responses) are **beyond    the
&gt; scope of this specification**, but
&gt; generally **involve an interaction    or
&gt; coordination between the resource
&gt; server and the authorization   
&gt; server**.

How does this interaction between resource server and authorization server work in practice?

 - How does the resource server
   determine that an access token it
   received is valid?
 - How does the
   resource server extract the allowed
   scope from the token to see if access should be granted to a particular resource? Is the Scope encoded in the access token, or does the resource server first have to contact the authorization server?
 - How is trust between the resource server and the authorization server established?

&gt; Access token attributes and the
&gt; methods used to access protected
&gt; resources are **beyond the scope of this
&gt; specification** and are defined by
&gt; companion specifications.

Can someone give examples for token attributes?

  [1]: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-16#section-7

OAuth v2 communication between authentication and resource server

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?

<p>I am exploring dependency injection and the term <strong>composition root</strong> is used all over the place. So what is it?</p>


Current situation: I have dependencies in my project that I solve by using dependency injection. I want to take the next logic step by using a dependency injection container (DIC) to ease the management of my dependencies and to lazy-load classes.

I looked at [Bucket](https://github.com/troelskn/bucket), [Pimple](http://pimple.sensiolabs.org/), and [sfServiceContainer](http://components.symfony-project.org/dependency-injection/), ran some test and really appreciate how DIC’s work. I’d probably go for Pimple because of its simplicity and raw power. If I didn’t have this problem:

Due to the abstraction that DIC’s offer, the IDE I’m using (PHPStorm) no longer understands what’s going on in my code. It doesn’t understand that $container[&#39;mailer&#39;] or $sc-&gt;mailer is holding a class object. I also tried Netbeans IDE: same problem.

This is really a problem for me because my IDE becomes useless. I don’t want to program without code hints, autocompletion and refactoring tools when dealing with classes. And I don’t want my IDE to find all kinds of false positives when validating code.

So my question is: Has anyone dealt with this problem and found a solution?

How do I make my PHP IDE understand Dependency Injection Containers?

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 most commonly am tempted to use &quot;bastard injection&quot; in a few cases.  When I have a &quot;proper&quot; dependency-injection constructor:

    public class ThingMaker {
        ...
        public ThingMaker(IThingSource source){
            _source = source;
        }

But then, for classes I am intending as **public APIs** (classes that other development teams will consume), I can never find a better option than to write a default &quot;bastard&quot; constructor with the most-likely needed dependency:

        public ThingMaker() : this(new DefaultThingSource()) {} 
        ...
    }

The obvious drawback here is that this creates a static dependency on DefaultThingSource; ideally, there would be no such dependency, and the consumer would always inject whatever IThingSource they wanted.  However, this is too hard to use; consumers want to new up a ThingMaker and get to work making Things, then months later inject something else when the need arises.  This leaves just a few options in my opinion:

 1. Omit the bastard constructor; force the consumer of ThingMaker to understand IThingSource, understand how ThingMaker interacts with IThingSource, find or write a concrete class, and then inject an instance in their constructor call. 
 2. Omit the bastard constructor and provide a separate factory, container, or other bootstrapping class/method; somehow make the consumer understand that they don&#39;t need to write their own IThingSource; force the consumer of ThingMaker to find and understand the factory or bootstrapper and use it.
 3. Keep the bastard constructor, enabling the consumer to &quot;new up&quot; an object and run with it, and coping with the optional static dependency on DefaultThingSource.

Boy, #3 sure seems attractive.  Is there another, better option?  #1 or #2 just don&#39;t seem worth it.

Is there an alternative to bastard injection? (AKA poor man&#39;s injection via default constructor)

From the [Dependency Injection in .NET][1] book I know that the object graph should be created at the `Composition Root` of the application which makes a lot of sense to me when you are using an `IoC Container`.

In all the applications I&#39;ve seen when an attempt to use DI is being made, there are always two constructors:

* the one with the dependencies as parameters and 
* the &quot;default&quot; one with no parameters which in turn calls the other one &quot;newing&quot; up all the dependencies

In the aforementioned book, however, this is called the &quot;Bastard Injection anti-pattern&quot; and that is what I used to know as &quot;Poor Man&#39;s Injection&quot;.

Now considering all this, I would say then that &quot;Poor Man&#39;s Injection&quot; would be just not using an `IoC Container` and instead coding all the object graph by hand on the said `Composition Root`. 

So my questions are:

1. Am I understanding these concepts correctly or am I completely off track?
2. If you still need to register all the dependencies in the IoC container vs. coding them by hand in the exact same Composition Root, what&#39;s the real benefit of using an IoC container?
3. If I have misunderstood what &quot;Poor Man&#39;s Injection&quot; really is, could someone please clarify it?


  [1]: https://manning.com/seemann

What is the real difference between &quot;Bastard Injection&quot; and &quot;Poor Man&#39;s Injection&quot;

I am going through some blogs on SpringSource and in one of the blogs, author is using `@Inject` and I suppose he can also use `@Autowired`.

Here is the piece of code:

`@Inject private CustomerOrderService customerOrderService;`

I am not sure about the difference between `@Inject` and `@Autowired` and would appreciate it if someone explained their difference and which one to use under what situation?

What is the difference between @Inject and @Autowired in Spring Framework? Which one to use under what condition?

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?

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 ...?

(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?

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)?

Content Type	Original Author	Original Content on Stackoverflow
Question	Thomas	View Question on Stackoverflow
Solution 1 - Dependency Injection	Sam Holder	View Answer on Stackoverflow
Solution 2 - Dependency Injection	DevTheJo	View Answer on Stackoverflow

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

Dependency Injection Problem Overview

Dependency Injection Solutions

Solution 1 - Dependency Injection

Solution 2 - Dependency Injection

OAuth v2 communication between authentication and resource server

How to disable warnings for particular include files?

Attributions