IoC containers usage

Get Started. It's Free
or sign up with your email address
Rocket clouds
IoC containers usage by Mind Map: IoC containers usage

1. Start

1.1. registration

1.1.1. XML

1.1.1.1. use mostly for configuration

1.1.2. in code (one by one)

1.1.3. via conventions

1.1.3.1. this should be the default and most common one

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

1.1.5. partition registration (installers/modules/registries)

1.1.5.1. one installer per one kind of components

1.1.5.1.1. controllers, repositories

1.1.5.1.2. installer per external framework: NHibernateInstaller

1.1.5.1.3. Name it in such a way it's obvious what it's responsible for

1.1.5.2. Keep all installers in your root project

1.1.5.2.1. that's most likely the only project that will have reference to your IoC container's assembly anyway

1.1.5.2.2. exception - extensions which will have their own installers most likely

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

1.2.1. right after you create your container

1.3. one container instance

1.3.1. created at applications start

2. Run

2.1. Resolve in one place

2.2. scoping and releasing

2.2.1. implicit (Autofac - lifetimescope.Dispose)

2.2.2. explicit (Windsor - container.Release)

2.2.3. container owns the components - container cleans up after them

2.3. factories for deferred resolve

2.3.1. as alternative to ServiceLocator

2.3.2. explicitly release what you explicitly resolve via the factory

2.3.2.1. be aware of lifestyle/lifetime - know when you can relax this rule

2.4. lifetime layering

2.4.1. shortlived component can depend on long lived components directly

2.4.2. long lived components can depend on short lived components via (long lived) factory

2.4.2.1. release then after you use them

2.4.2.1.1. Windsor: factory.IDontNeedThisAnymore

2.4.2.1.2. Autofac: use Owned<T>

2.5. zombie objects (memory leaks)

2.5.1. components need to be released (directly or indirectly)

3. Close

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

3.2. gracefully shut down entire container

3.3. releases all components (incl. transient)

4. Development

4.1. LEGO analogy has it backwards

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

4.2. When it's OK to use "new"

4.2.1. what makes a component

4.3. be tidy and consistent

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

4.4. Container is not a magic wand or replacement for good design

4.4.1. SOLID

4.4.2. Hollywood principle

4.4.3. DRY

4.5. IoC and Service Locator

4.5.1. Avoid SL

4.5.1.1. Breaks the abstraction

4.5.1.2. Hides dependencies

4.5.1.3. Makes things hard to test

4.5.1.4. Encourages bad behaviour

4.5.2. Avoid abstracting the container (CLS)

4.5.2.1. Has all advantages of SL which it is

4.5.2.2. Lowest common denominator - you give up 95% of container's power

4.6. Be aware of your container's capabilities and utilize them

4.6.1. Features (AOP, startable, strongly typed configuration)

4.6.1.1. the code you don't have to write

4.6.2. Integration with other frameworks/libraries (WCF, NHibernate, log4net)

4.6.2.1. simplifies the code, adds features

5. Testing

5.1. registration

5.1.1. right types are registered

5.1.1.1. as right servces

5.1.1.2. properly configured

5.1.2. can be resolved properly

5.2. container customizations/extensions

5.3. validate conventions (not limited to the container)