Comparison
Composition rootvsObject graph
Composition root
there is exactly one file that knows every concrete class, and it is the one that runs at startup.
The single place — as close to the entry point as possible — where the object graph is assembled and concrete types are chosen. Keeping it to one place is what makes the rest of the codebase free of construction logic, and it is the answer to 'if nobody news anything up, who does'. A codebase with several composition roots, or with one buried in a service, is one where nobody can say what actually runs.
Full entry →Object graph
one request for the top-level object built nineteen things underneath it, and you only asked for one.
The tree of instances a component and its transitive dependencies form once constructed. Thinking of wiring as producing a graph rather than a list is what makes lifetime questions tractable — which nodes are shared, which are per-request, which are new every time. It is also the thing a container error message is describing when it names a resolution path five levels deep.
Full entry →