Your SlideShare is downloading. ×
A lap around IoC containers with Castle Windsor
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

A lap around IoC containers with Castle Windsor


Published on

My session from SDP May 2013

My session from SDP May 2013

Published in: Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Remember to call Release for each Resolve.
  • Transcript

    • 1. SELA DEVELOPER PRACTICE May 5-9, 2013 A Lap Around Inversion of Control Containers With Castle Windsor Moshe Levi Consultant, SELA Group @levimos
    • 2. First Things First - Definitions • Inversion of Control • Instead of you calling the framework, the framework calls you (the Hollywood principle). For example : WCF Behaviors, Prism Modules • Dependency Injection • Object’s dependencies are passed into it, rather than the object creating them directly • Inversion of Control Container • Uses IoC to manage the creation of classes • Uses DI to “inject” dependencies into objects
    • 3. First Things First – Definitions – Cont’ • Service • “An Abstract contract describing some cohesive unit of functionality”. • Usually an interface • Component • Provides one or more services • Usually a class that implements the service’s interface • In a well-designed application, you end up having a lot of small components, exposing small, well-defined, abstract services, depending on services provided by other components
    • 4. Sample – Without Dependency Injection • How do you test RegistrationService without an internet connection? • How do you send an SMS instead of an email?
    • 5. Sample - With Dependency Injection • How are EmailNotifer and RegistrationSerivce instantiated?
    • 6. What Is It Good For? • Creates maintainable and testable software by producing loosely-coupled code • The benefit is getting bigger and bigger as new components and dependencies are added because there is only one central place of construction
    • 7. Who is on board? • Castle Windsor • Unity • StructureMap • Ninject • Autofac • TinyIoC • SpeedIoC • Funq • More…
    • 8. A Typical Usage • Creating: • Registering: • Resolving: • Releasing:
    • 9. Basic Registration • A component is registered as an implementation for a service • Multiple components can be registered for a single service • First registered component is returned by default • The default can be overridden by using IsDefault() • Components can be named. The name can be used to resolve a specific component for a given service • A component can be registered for more than one service • Component composition can be customized by using DependsOn
    • 10. Understanding Lifestyles • Singleton (The default lifestyle) • An instance is created the first time the component is requested • The same instance is returned for subsequent requests • Transient • A new instance is created each time the component is requested • Scoped • Behaves as a singleton within the scope • Automatically being released at the end of the scope • Bound
    • 11. Understanding Lifestyles – Cont’ • PerThread • A single instance is created for each thread from which the component is requested • Pooled • A pool of instances is created when the component is first requested • The pool’s size can be controlled by setting its initialSize and maxSize parameters • Implement IRecyclable to allow recycling
    • 12. Understanding Lifecycles • The creation and destruction of components is the container’s responsibility. Never call Dispose or other clean-up method yourself • You can add your own logic through several extension points • Commission concerns: • Call OnCreate upon component registration • Implement Castle.Core.IInitializable • Implement System.ComponentModel.ISupportInitialize • Decommission concerns: • Call OnDestroy upon component registration • Implement IDisposable
    • 13. Using Installers • Installers are used to encapsulate and partition the registration logic • Implement a separate IWindsorInstaller for each group of components (Services, ViewModels, etc…) • Windsor accepts installers in two ways: • By calling the Install method with a list of installers • By using the FromAssembly class
    • 14. Using Conventions – Selecting Components • Registering components one-by-one can be tedious and repetitive job and may lead to bugs • Use the various methods defined in the Classes and Types static classes to register groups of components based on conventions
    • 15. Using Conventions – Selecting Services • By default, the service of the component is the type itself • Use the various methods of the WithService static class to override it. For Example: • Base – Base interface is chosen as the component’s service • DefaultInterfaces – Selects interface with matching name as a service (IViewModel will be chosen for ViewModel) • AllInterfaces – Registers the type for all its interfaces
    • 16. Three Calls Pattern • The container itself is a dependency. Do not use it directly. Hide it in the framework. • Makes your classes more understandable, as it is immediately known what dependencies they have. • Which implementation is more readable?
    • 17. Three Calls Pattern – Cont’ • Register • Create the container and register all the components • Resolve • Only the application’s root component is directly resolved from the container. • All the sub components are automatically constructed by the container to construct the root component. • Release • Release the root component and dispose the container
    • 18. Typed Factories • Are used when a component’s dependency is needed during the lifetime of the component • Automatically generated by the TypedFactoryFacility • Interface-based factory • Can be used to release components • Delegate-based factory • No registration is required • Released only when the factory is disposed • Both of them can receive additional dependencies
    • 19. Handler Selectors • Allows you to add your own logic to dynamically choose a component to satisfy a requested service by implementing the IHandlerSelector interface • HasOpinionAbout – “Would you like to select a handler for the given service?” • SelectHandler – “Please select a single handler from the ones available for the service” • Selectors need to be registered with the container
    • 20. Doing AOP with Windsor • Interceptors can be used to apply cross cutting concerns for your components • Implement the IInterceptor interface • Register your interceptor like any other component • Use the Interceptors<T> fluent API to attach interceptors to components: • As before, Windsor will take care of the rest for you
    • 21. Debugging and Diagnostics • Windsor provides a custom debugger view • All Components – A list of all the registered components • Each component contains the following properties: Service, Implementation, Status , Lifestyle, Name • Status is the place to look for errors • All Services – A list of all the registered services • Potentially misconfigured components – A list of components that have some unresolved dependencies (statically) • Objects tracked by release policy – A list of objects with decommission concerns that are tracked by the container. • This is the place to look for potential memory leaks.
    • 22. Further Reading • Martin Fowler – Inversion of Control Containers and the Dependency Injection Pattern • Castle Windsor Documentation
    • 23. Thank You