Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
IoC containers usage создатель Mind Map: IoC containers usage

1. Start

1.1. registration

1.1.1. XML use mostly for configuration

1.1.2. in code (one by one)

1.1.3. via conventions 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) 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 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

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 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 release then after you use them Windsor: factory.IDontNeedThisAnymore 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 Breaks the abstraction Hides dependencies Makes things hard to test Encourages bad behaviour

4.5.2. Avoid abstracting the container (CLS) Has all advantages of SL which it is 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) the code you don't have to write

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

5. Testing

5.1. registration

5.1.1. right types are registered as right servces properly configured

5.1.2. can be resolved properly

5.2. container customizations/extensions

5.3. validate conventions (not limited to the container)