Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

IoC containers usage by Mind Map: IoC containers usage
0.0 stars - reviews range from 0 to 5

IoC containers usage



XML, use mostly for configuration

in code (one by one)

via conventions, this should be the default and most common one

you can (and likely will) mix and match all of them

partition registration (installers/modules/registries), one installer per one kind of components, controllers, repositories, installer per external framework: NHibernateInstaller, Name it in such a way it's obvious what it's responsible for, so that you can quickly find it, because there's no direct reference to it, or classes it registers in the code, so that you don't stop and think "where should I register that class...", Keep all installers in your root project, that's most likely the only project that will have reference to your IoC container's assembly anyway, exception - extensions which will have their own installers most likely

All registration and configuration should happen in one place container.Install

right after you create your container

one container instance

created at applications start


Resolve in one place

scoping and releasing

implicit (Autofac - lifetimescope.Dispose)

explicit (Windsor - container.Release)

container owns the components - container cleans up after them

factories for deferred resolve

as alternative to ServiceLocator

explicitly release what you explicitly resolve via the factory, be aware of lifestyle/lifetime - know when you can relax this rule

lifetime layering

shortlived component can depend on long lived components directly

long lived components can depend on short lived components via (long lived) factory, release then after you use them, Windsor: factory.IDontNeedThisAnymore, Autofac: use Owned<T>

zombie objects (memory leaks)

components need to be released (directly or indirectly)


Call at the end of the app (container.Dispose)

gracefully shut down entire container

releases all components (incl. transient)


LEGO analogy has it backwards

it's not putting bricks together where the fun is - it's building the bricks

When it's OK to use "new"

what makes a component

be tidy and consistent

make structure of your project work for you - conventions, conventions, conventions

Container is not a magic wand or replacement for good design


Hollywood principle


IoC and Service Locator

Avoid SL, Breaks the abstraction, Hides dependencies, Makes things hard to test, Encourages bad behaviour

Avoid abstracting the container (CLS), Has all advantages of SL which it is, Lowest common denominator - you give up 95% of container's power

Be aware of your container's capabilities and utilize them

Features (AOP, startable, strongly typed configuration), the code you don't have to write

Integration with other frameworks/libraries (WCF, NHibernate, log4net), simplifies the code, adds features



right types are registered, as right servces, properly configured

can be resolved properly

container customizations/extensions

validate conventions (not limited to the container)