Castle Windsor Documentation

Castle Windsor is designed to be extended rather than providing every capability out of the box. It exposes several layers of extension points that allow you to modify or augment the container's behavior. These range from low-level subsystems to high-level facilities and lifecycle management.

Common extension points include:

• Facilities: The primary extension point, often encompassing multiple other extension points.
• Lifestyle Managers: Control when instances are created, reused, or disposed.
• Lifecycle Concerns: Execute logic during component creation or decommissioning.
• Handler Selectors: Custom logic for selecting components (useful for multi-tenant apps).
• Component Activators: Control the actual instantiation process of components.
• Resolvers: Override the logic used to resolve components.
• ComponentModel Construction Contributors: Inspect or modify the ComponentModel during registration.
• Lazy Component Loaders: Enable just-in-time registration (e.g., pulling from MEF or WCF).
• Model Interceptors Selectors: Dynamically select interceptors for specific components.
• Release Policy: Handle how components are tracked and released.
• SubSystems: The innermost extension point, rarely swapped.
• Container Events: Subscribe to events occurring within the container.

The WCF Integration facility enables integration with Windows Communication Foundation (WCF) by providing several key features:

Client-side features

• Dynamic Proxy Replacement: Windsor replaces standard WCF client-side remoting proxies with its own Dynamic Proxy. This allows you to apply interceptors to WCF proxies just like any other Windsor component.
• Asynchronous Calls: Enables performing asynchronous calls without the need for code-generated client-side proxies.
• Channel Recycling: Provides the ability to transparently recycle the channel when it gets closed or faulted.

Server-side features

• WCF Lifestyles: Provides specialized lifestyles such as PerWcfSession and PerWcfOperation for managing component lifetimes within WCF service contexts.

General features

• Makes services and WCF proxies available as services in your application.
• Supports non-default constructors and dependency injection into WCF services.
• Allows easy service setup using extensions.

The tutorial is divided into two main phases: getting started and advanced implementation.

Phase 1: Getting Started

• Getting Windsor: Downloading and adding Windsor assemblies to your project.
• Plugging Windsor In: Creating a custom controller factory to bridge ASP.NET MVC and Windsor.
• Writing Your First Installer: Creating Windsor installers and testing them (validating conventions).
• Putting It All Together: Integrating all components into a working application.

Phase 2: Advanced Implementation

• Logging Support: Using Windsor's logging facility.
• Persistence Layer: Creating custom facilities, registering externally created objects, and setting up NHibernate.
• Lifestyles: Using different lifestyles, specifically per-web-request.
• Satisfying Dependencies: Understanding dependency resolution and specification approaches.
• Diagnosing Issues: Troubleshooting exceptions thrown by the container when dependencies are missing.

A component is a concrete implementation of one or more services. While a service is an abstract contract, a component is the actual entity managed by the container that performs the work.

Key characteristics of components:

• Implementation: Usually a class that implements a service interface.
• Multiplicity: You can have multiple components that implement the same service (e.g., two different coffee shop implementations).
• Shared Implementation: Multiple distinct components can be backed by the same class but configured differently (e.g., two instances of a database session factory class, each with different connection strings).
• Multiple Services: A single component can expose multiple different services.
• Exclusion: Classes that do not provide services (like DTOs or pure domain models) are generally not registered as components in the container.

public class Starbucks: ICoffeeShop
{
   public Future<Coffee> GetCoffee(CoffeeRequest request)
   {
      // some implementation
   }
}