Szczerze powiedziawszy, ciężko jest określić polską nazwę dla interfejsu IContributeComponentModelConstruction. Powiedzmy, że na potrzebę tego wpisu będę się posługiwać sformułowaniem inspektor. A w samym wpisie opiszę czym jest i jak używać inspektorów.

Inspektor

Klasa implementująca interfejs IContributeComponentModelConstruction ma wgląd w metadane komponentów. Taki inspektor według dedykowanej logiki może zmienić konfigurację zarejestrowanego serwisu. Sam Castle posiada kilka wbudowanych inspektorów, które związane są m.in. z proxy, zależnościami, czy zarządzaniem trybem życia komponentów. Implementacje tego interfejsu uruchamiane są zaraz po zebraniu metadanych odnośnie zarejestrowanego komponentu.

Nie zaleca się modyfikowania wartości metadanych instancji ComponentModel poza inspektorami.

Definicja interfejsu jest następująca:

namespace Castle.MicroKernel.ModelBuilder
{
  /// <summary>
  /// Implementors must inspect the component for a given information or parameter.
  /// 
  /// </summary>
  public interface IContributeComponentModelConstruction
  {
    /// <summary>
    /// Usually the implementation will look in the configuration property
    ///               of the model or the service interface, or the implementation looking for
    ///               something.
    /// </summary>
    /// <param name="kernel">The kernel instance</param><param name="model">The component model</param>
    void ProcessModel(IKernel kernel, ComponentModel model);
  }
}

Widzimy, że interfejs eksponuje jedną metodę, która przyjmuje parametry o typach IKernel oraz ComponentModel.

Podpięcie dedykowanego inspektora polega na dodaniu własnej implementacji do kolekcji inspektorów:

container.Kernel.ComponentModelBuilder.AddContributor(new MyContributor());

Przykład

Troszkę ciężko jest wymyślić jakiś sensowny przykład bez kontekstu, który będzie ładnie potrafił ukazać działanie przykładowego inspektora.
Widok na solution:

Powiedzmy, że będziemy chcieli umieć zmienić tryb życia komponentu w zależności czy zostanie on oznaczony specjalnym atrybutem. Nazwijmy ten atrybut TransientAttribute. Jego definicja jest prosta, a sam atrybut służy jedynie jako "marker" do oznaczania klas:

using System;
namespace WindsorContributors
{
    public class TransientAttribute : Attribute
    {
    }
}

Zdefiniujmy dwa serwisy,  które będą użyte w tym projekcie. Jeden z nich będzie miał cykl życia Singleton, natomiast cykl durugiego ulegnie zmianie przez wpięcie naszego kontrybutora. Jak widać w drugim przypadku SingletonChangedService jest oznaczony atrybutem Transient.

namespace WindsorContributors
{
    public class SingletonService
    {
    }

    [Transient]
    public class SingletonChangedService
    {
    }
}

Definicja Instalatora zależności zakłada rejestrację komponentów z trybem życia Singleton (domyślnie Windsor Castle ustawia taki tryb, jeżeli nie został on explicite wskazany):

using Castle.MicroKernel.Registration;
using Castle.MicroKernel.SubSystems.Configuration;
using Castle.Windsor;

namespace WindsorContributors
{
    public class WindsorInstaller : IWindsorInstaller{
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            container.Register(
                Component.For<SingletonService>(),
                Component.For<SingletonChangedService>()
                );
        }
    }
}

No i wreszcie samo mięsko: inspektor sprawdza tryb życia i istnienie atrybutu Transient. Jeżeli te warunki są spełnione, to komponent otrzymuje tryb życia Transient.

using Castle.Core;
using Castle.MicroKernel;
using Castle.MicroKernel.ModelBuilder;

namespace WindsorContributors
{
    public class TransientAttributeInspector : IContributeComponentModelConstruction
    {
        public void ProcessModel(IKernel kernel, ComponentModel model)
        {
            if (model.LifestyleType != LifestyleType.Transient)
            {
                var hasAttribute = model.Implementation.GetCustomAttributes(typeof (TransientAttribute), false).Length > 0;
                if (hasAttribute)
                {
                    model.LifestyleType = LifestyleType.Transient;
                }
            }            
        }
    }
}

Główne wejście programu. Zwróćmy uwagę na kolejność w jakiej rejestrujemy inspektor oraz wskazujemy na instalator zależności.

using System;
using Castle.Windsor;

namespace WindsorContributors
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var container = new WindsorContainer())
            {
                container.Kernel.ComponentModelBuilder.AddContributor(new TransientAttributeInspector());
                container.Install(new WindsorInstaller());
                var singleton1 = container.Resolve<SingletonService>();
                var singleton2 = container.Resolve<SingletonService>();
                var transient1 = container.Resolve<SingletonChangedService>();
                var transient2 = container.Resolve<SingletonChangedService>();

                Console.WriteLine("Wartości singleton1 i singleton2 są równe: {0}", singleton1.Equals(singleton2));
                Console.WriteLine("Wartości transient1 i transient2 są równe: {0}", transient1.Equals(transient2));
                Console.ReadKey();
            }
        }
    }
}

W rezultacie otrzymujemy następujący output z konsoli. Można by rzec w ujęciu matematycznym CND.

Wartości singleton1 i singleton2 są równe: True
Wartości transient1 i transient2 są równe: False

Podsumowanie

Jednym z głównych i ciekawych spostrzeżeń jest to, że należy w pierwszej kolejności wskazać inspektory, a następnie zainstalować komponenty. W przeciwnym razie, nasz inspektor nie zostanie wywołany, a oczekiwany rezultat nie będzie otrzymany.

Innym spostrzeżeniem jest to, że inspektory mają dostęp do metadanych zarejestrowanych komponentów. W inspektorze nie mamy dostępu do instancji, ale tylko metadanych rejestrowanych komponentów.

Bibliografia

Głównie ze strony Castla: http://docs.castleproject.org/Windsor.ComponentModel-construction-contributors.ashx

Komponenty tworzone przez kontener posiadają swój cykl życia. Cykl życia określa warunki w jakich są tworzone, używane oraz niszczone. W Castle można skonfigurować mechanizmy, które w sposób dedykowany  będą umiały zarządzać dodatkową logiką przy powoływaniu oraz niszczeniu wcześniej utworzonych instancji. Wpis ten nie będzie omawiał dedykowanych zarządców powoływania i odwoływania instancji.

Powoływanie

W kontenerze w odniesieniu do tworzenia obiektów użyte jest sformułowanie"commission concerns". Metody powoływujące są uruchamiane na rzecz wcześniej już zinstancjonowanych komponentów, dla których zostały wstrzyknięte wszystkie zależności. Konfigurując więc conmmision concerny musimy mięć na uwadze, że otrzymujemy gotową do użycia instancję. Castle w trójnasób wspiera powoływanie obiektów poprzez wywołanie metody OnCreate w rejestratorze, implementację interfejsu IInitializable lub ISupportInitialize.

OnCreate

Jest to metoda, której można użyć na konfiguratorze rejestracji, jeżeli chcemy skonfigurować inline przetwarzanie instancji zaraz po jej inicjalizacji. Poniżej został przedstawiony listing użycia API na podstawie przykładu ze strony Castla:

container.Register(
   Component.For<IService>()
      .ImplementedBy<MyService>()
      .OnCreate((kernel, instance) => instance.Timestamp = DateTime.UtcNow)
   );

IInitializable

Interfejs ten jest ulokowany w przestrzeni nazw Castle.Core. Castle traktuje w sposób szczególny klasy implementujące ten interfejs - jest on uruchamiany po podstawowej inicjalizacji instancji. Jedynym minusem użycia tego interfejsu jest to, że nie można przekazać żadnych zależności z zewnątrz do takiej instancji.

void Initialize();

ISupportInitalization

W przypadku, jeżeli nie chcemy mieć bezpośredniego odwołania do Castle w domenie,  można posłużyć się niezależnym interfejsem ISupportInitalization z przestrzeni nazw System.ComponentModel. Interfejs tak samo jak w powyższym przypadku ma ograniczenie odnośnie uzyskiwania dodatkowych zależności od kontenera. Metody BeginInit oraz EndInit wywoływane są bezpośrednio po sobie, więc nie ma znaczenia w której z nich umieścimy logikę inicjalizacyjną.

void BeginInit();
void EndInit();

Odwoływanie

Udział w odwoływaniu obiektów (decomission) można zrealizować na dwa sposoby: wywołanie metody OnDestroy w rejestratorze lub implementację interfejsu IDisposable. Castle trzyma odniesienia do każdej encji, którą stworzył. Ważne jest, aby pamiętać o odpowiednim zarządzaniu pamięcią i zwalnianiu zasobów, kiedy nie są już używane.

OnDestroy

Jest to metoda analogiczna w stosunku do OnCreate, przy czym w tym przypadku nie mamy "w ręku" implementacji IKernel. Poniżej został przedstawiony listing użycia API na podstawie przykładu ze strony Castla:

container.Register(Component.For<MyClass>()
   .LifestyleTransient()
   .OnDestroy(myInstance => myInstance.ByeBye())
);

IDisposable

W tym przypadku kontener jest w stanie obsłużyć standardowy interfejs IDisposable używany przez .NET przy niszczeniu obiektów. Jeżeli dana instancja będzie miała być zniszczona, to zostanie wywołana metoda Dispose.

Przykład - eksperyment

W przykładzie pokażę sposób użycia wyżej wymienionych implementacji. Będziemy mieli następujące komponenty: IService wraz z implementacją MyService oraz DateTimeProvider wstrzykiwany do tej implementacji .

using System;
using System.ComponentModel;
using Castle.Core;

namespace CommissionConcerns
{
    public interface IService
    {
    }

    public class MyService : IService, ISupportInitialize, IInitializable, IDisposable
    {
        private readonly DateTimeProvider _dateTimeProvider;

        public MyService(DateTimeProvider dateTimeProvider)
        {
            _dateTimeProvider = dateTimeProvider;
            Console.WriteLine("MyService.ctor {0}", _dateTimeProvider.GetCurrentDateTime());
        }

        public void BeginInit()
        {
            Console.WriteLine("BeginInit()");
        }

        public void EndInit()
        {
            Console.WriteLine("EndInit()");
        }

        public void Initialize()
        {
            Console.WriteLine("Initialize()");
        }

        public void Dispose()
        {
            Console.WriteLine("Dispose()");
        }
    }

    public class DateTimeProvider
    {
        public DateTime GetCurrentDateTime()
        {
            return DateTime.Now;
        }
    }
}

Rejestracje oraz konfiguracja powoływania oraz odwoływania instancji:

using System;
using Castle.MicroKernel.Registration;
using Castle.MicroKernel.SubSystems.Configuration;
using Castle.Windsor;

namespace CommissionConcerns
{
    internal class WindsorInstaller : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            container.Register(
                Component
                    .For<IService>()
                    .ImplementedBy<MyService>()
                    .OnCreate(
                        (kernel, instance) => Console.WriteLine("OnCreate: instance is null = {0}",  instance == null))
                    .OnDestroy(
                        (kernel, instance) => Console.WriteLine("OnDestroy: instance is null = {0}",  instance == null)),
                Component
                    .For<DateTimeProvider>()
                );
        }
    }
}

Oraz widok na listing z metody Main:

using System;
using Castle.Windsor;

namespace CommissionConcerns
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            using (var container = new WindsorContainer())
            {
                container.Install(new WindsorInstaller());
                var service = container.Resolve<IService>();
                Console.WriteLine("After object comission");
            }

            Console.WriteLine("After object decomission");
            Console.ReadKey();
        }
    }
}

Rezultat wykonania przykładu:

MyService.ctor 12/10/2013 20:37:53 AM
OnCreate: instance is null = False
Initialize()
BeginInit()
EndInit()
After object comission
OnDestroy: instance is null = False
Dispose()
After object decomission

Wnioski

Windsor Castle dostarcza kilka miejsc rozszerzeń, dzięki którym można kontrolować proces inicjalizacji oraz niszczenia instancji. Co więcej, konfiguracja umożliwia zdefiniowanie logiki inicjalizacji wprost przy rejestracji komponentu lub poprzez implementację interfejsu z przestrzeni nazw Castle lub systemowych. Przy czym przy drugim podejściu nie musimy skazywać np. projektu domeny na bezpośrednią referencję do kontenera. Innym wnioskiem jest to, że poszczególne podejścia zajmują swoje ustalone miejsce w kolejności wywoływania.

Bibliografia

Głównie http://docs.castleproject.org/Windsor.Lifecycle.ashx.

Wpis nawiązuje do poprzedniego, teoretycznego wprowadzenia do trybów życia w Windsor Castle. W tym przykładzie spróbujemy posłużyć się semi-biznesowym przypadkiem. Powiedzmy, że mamy system do składania zamówień, który na podstawie kodu produktu oraz pewnej konfiguracji, będzie potrafił udzielić zniżki na wybrany produkt. Zepniemy te bardzo "wybujałe" wymagania i dostarczymy projekt w technologii ASP.NET MVC.

Modele, kontrolery, widoki i walidatory

Poniżej przedstawiłem screen z widokiem na solution tego projektu. W dalszych akapitach krótko scharakteryzuje standardowe byty jak dla aplikacji ASP.NET MVC , a później przedstawię koncepcję podpięcia Windsora do tego projektu.

Poniżej znajduje się listing do Product.cs. Niczego specjalnego tutaj nie mamy. Ot taka zwykła encja, mamy kod produktu, liczbę zamówionych egzemplarzy oraz informację o tym, czy zostanie udzielona zniżka.

namespace WindsorLifeStyles.Models
{
    public class Product
    {
        public int Id { get; set; }

        public string Code { get; set; }

        public int Quantity { get; set; }

        public bool Discount { get; set; }
    }
}

Kontroler ProductsController.cs steruje logiką zarządzania przydzielania zniżki użytkownikowi, który zamierza kupić dany produkt. Jako zależności do kontrolera produktów, wstrzykiwane są dwa komponenty - ProductDiscountCache oraz CurrentUserProvider. Do ViewBaga widoku doklejamy informacje o liczbie wywołań poszczególnych komponentów - kontrolera, providera id użytkownika oraz cache zniżek produktów.

using System.Web.Mvc;
using WindsorLifeStyles.Models;
using WindsorLifeStyles.Services;

namespace WindsorLifeStyles.Controllers
{
    public class ProductsController : Controller
    {
        private readonly ProductDiscountCache _productDiscountCache;
        private readonly CurrentUserProvider _currentUserProvider;
        private int _calls;
        public ProductsController(
            ProductDiscountCache productDiscountCache,
            CurrentUserProvider currentUserProvider)
        {
            _productDiscountCache = productDiscountCache;
            _currentUserProvider = currentUserProvider;
        }

        public ActionResult Index()
        {
            _calls++;
            SetCallsData();
            return View(new Product());
        }

        [HttpPost]
        [ValidateAntiForgeryToken]
        public ActionResult Index(Product product)
        {
            _calls++;

            if (ModelState.IsValid)
            {
                var currentUserId = _currentUserProvider.GetCurrentUserId();
                product.Discount = _productDiscountCache.HasDiscount(product.Code, currentUserId);

                SetCallsData();
                return View("Details", product);
            }

            SetCallsData();
            return View(product);
        }

        private void SetCallsData()
        {
            ViewBag.GetCurrentUserCalls = _currentUserProvider.GetCalls;
            ViewBag.HasDiscountCalls = _productDiscountCache.GetCalls;
            ViewBag.ControllerCalls = _calls;
        }
    }
}

Widok Details.cshtml wyświetla podsumowanie zamówienia produktu oraz liczbę wywołań poszczególnych komponentów.

@model WindsorLifeStyles.Models.Product

@{
    ViewBag.Title = "Details";
}

<h2>Details</h2>

<fieldset>
    <legend>Product</legend>

    <div class="display-label">
        @Html.DisplayNameFor(model => model.Code)
    </div>
    <div class="display-field">
        @Html.DisplayFor(model => model.Code)
    </div>

    <div class="display-label">
        @Html.DisplayNameFor(model => model.Quantity)
    </div>
    <div class="display-field">
        @Html.DisplayFor(model => model.Quantity)
    </div>

    <div class="display-label">
        @Html.DisplayNameFor(model => model.Discount)
    </div>
    <div class="display-field">
        @Html.DisplayFor(model => model.Discount)
    </div>
    <div class="display-field">
        ControllerCalls:  @ViewBag.ControllerCalls
    </div>
    <div class="display-field">
        GetCurrentUserCalls:  @ViewBag.GetCurrentUserCalls
    </div>
    <div class="display-field">
        HasDiscountCalls:  @ViewBag.HasDiscountCalls
    </div>       
</fieldset>

Z kolei widok Index.cshtml prezentuje formularz dodawania produktu.

@model WindsorLifeStyles.Models.Product

@{
    ViewBag.Title = "Create";
}

<h2>Create</h2>

@using (Html.BeginForm())
{
    @Html.AntiForgeryToken()
    @Html.ValidationSummary(true)

    <fieldset>
        <legend>Product</legend>

        <div class="editor-label">
            @Html.LabelFor(model => model.Code)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Code)
            @Html.ValidationMessageFor(model => model.Code)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.Quantity)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Quantity)
            @Html.ValidationMessageFor(model => model.Quantity)
        </div>

        <p>
            <input type="submit" value="Create" />
        </p>
        <div class="display-field">
            ControllerCalls:  @ViewBag.ControllerCalls
        </div>
        <div class="display-field">
            GetCurrentUserCalls:  @ViewBag.GetCurrentUserCalls
        </div>
        <div class="display-field">
            HasDiscountCalls:  @ViewBag.HasDiscountCalls
        </div>
    </fieldset>
}

@section Scripts {
    @Scripts.Render("~/bundles/jqueryval")
}

Komponent CurrentUserProvider dostarcza informacji o identyfikatorze zalogowanego użytkownika. W tym przypadku zawsze tym identyfikatorem jest liczba 1, ale w prawdziwej implementacji provider ten powinien odwoływać się do mechanizmu uwierzytelniającego. W odniesieniu do stylu życia, komponent ten skonfigurujemy jako PerWebRequest, gdyż identyfikator zalogowanego użytkownika w ramach jednego requesta się nie zmienia. Co więcej jest to pewnego rodzaju optymalizacja, gdyż wywołanie tego providera może odbyć się wielokrotnie przy jednym requeście.

namespace WindsorLifeStyles.Services
{
    public class CurrentUserProvider
    {
        private int _calls;

        public int GetCalls
        {
            get { return _calls; }
        }

        public long GetCurrentUserId()
        {
            _calls++;
            return 1;
        }
    }
}

ProductDiscountCache jest komponentem, który dostarcza cache zmieniający się niezwykle rzadko lub wcale. Dobrym stylem życia dla tego komponentu jest Singleton. Przeładowanie cache odbędzie się w momencie, gdy kontener zostanie podniesiony od nowa, co stanie się przy restarcie puli. Natomiast sama implementacja leniwie odczytuje dane (wzorzec Lazy Loading), które zapisuje do słownika.

using System;
using System.Collections.Generic;

namespace WindsorLifeStyles.Services
{
    public class ProductDiscountCache
    {
        private readonly Lazy<Dictionary<string, IList>> _cache;

        private int _calls;

        public int GetCalls
        {
            get { return _calls; }
        }

        public ProductDiscountCache()
        {
            _cache = new Lazy<Dictionary<string, IList>>(GetCache);
        }

        private Dictionary<string, IList> GetCache()
        {
            return new Dictionary<string, IList>
                {
                    {"A", new List {1, 2, 3}},
                    {"B", new List {1}},
                    {"C", new List {2, 3}},
                };
        }

        public bool HasDiscount(string code, long currentUserId)
        {
            _calls++;

            var cache = _cache.Value;
            if (cache.ContainsKey(code))
            {
                var userIds = cache[code];
                return userIds.Contains(currentUserId);
            }

            return false;
        }
    }
}

Walidacja

Istotną składową tego projektu pod kątem zrozumienia trybu życia komponentów jest walidacja produktu, która również na podstawie CurrentUserProvider oraz ProductDiscountCache jest w stanie ustalić, czy użytkownik może dostać zniżkę na określoną liczbę produktów. W następnych akapitach napiszę jak sprytnie zintegrować walidację ASP.NET MVC z WindsorCastle.

using System.Collections.Generic;
using System.Web.Mvc;
using WindsorLifeStyles.Models;
using WindsorLifeStyles.Services;

namespace WindsorLifeStyles.Validators
{
    public class ValidadatorProvider : ModelValidatorProvider
    {
        private readonly CurrentUserProvider _currentUserProvider;
        private readonly ProductDiscountCache _productDiscountCache;

        public ValidadatorProvider(CurrentUserProvider currentUserProvider, ProductDiscountCache productDiscountCache)
        {
            _currentUserProvider = currentUserProvider;
            _productDiscountCache = productDiscountCache;
        }

        public override IEnumerable GetValidators(ModelMetadata metadata, ControllerContext context)
        {
            if (metadata.Model != null)
            {
                if (typeof (Product).IsAssignableFrom(metadata.ModelType))
                {
                    yield return new ProductValidator(metadata, context, _currentUserProvider, _productDiscountCache);
                }
            }
        }
    }
}

W ramach tego projektu mamy tylko jeden walidator - ProductValidator, który sprawdza czy użytkownik przypadkiem nie zamierza kupić więcej niż 3 produktów ze zniżką. Jeżeli ten warunek nie będzie spełniony, walidacja się nie powiedzie, a kupujący otrzyma komunikat o błędzie.

using System.Collections.Generic;
using System.Web.Mvc;
using WindsorLifeStyles.Models;
using WindsorLifeStyles.Services;

namespace WindsorLifeStyles.Validators
{
    public class ProductValidator : ModelValidator
    {
        private readonly CurrentUserProvider _currentUserProvider;
        private readonly ProductDiscountCache _productDiscountCache;

        public ProductValidator(
            ModelMetadata metadata,
            ControllerContext controllerContext,
            CurrentUserProvider currentUserProvider,
            ProductDiscountCache productDiscountCache)
            : base(metadata, controllerContext)
        {
            _currentUserProvider = currentUserProvider;
            _productDiscountCache = productDiscountCache;
        }

        public override IEnumerable Validate(object container)
        {
            var product = (Product) Metadata.Model;
            var currentUserId = _currentUserProvider.GetCurrentUserId();
            var hasDiscount = _productDiscountCache.HasDiscount(product.Code, currentUserId);
            if (hasDiscount && product.Quantity > 3)
            {
                yield return new ModelValidationResult
                    {
                        MemberName = "Quantity",
                        Message = "Użytownik, który otrzyma zniżkę, nie może zakupić więcej niż 3 produkty."
                    };
            }
        }
    }
}

I teraz chyba najważniejsza rzecz: utworzenie dedykowanego providera (RootModelValidatorProvider.cs), który potrafi każdorazowo wyciągnąć z kontenera listę walidatorów. Dlaczego tak ? Ano, chcemy, aby każdorazowo walidatory miały możliwość wstrzyknięcia zależności od kontenera.

using System.Collections.Generic;
using System.Linq;
using System.Web.Mvc;
using Castle.MicroKernel;

namespace WindsorLifeStyles
{
    public class RootModelValidatorProvider : ModelValidatorProvider
    {
        private readonly IKernel _kernel;

        public RootModelValidatorProvider(IKernel kernel)
        {
            _kernel = kernel;
        }

        public override IEnumerable GetValidators(ModelMetadata metadata, ControllerContext context)
        {
            var modelValidators =
                _kernel.ResolveAll()
                       .SelectMany(n => n.GetValidators(metadata, context))
                       .ToList();
            return modelValidators;
        }
    }
}

Wpięcie Windsor Castla w ASP.NET MVC

Przyjrzyjmy się najpierw instalatorowi zależności(WindsorInstaller.cs). Wskazujemy do rejestracji:

• wszystkie implementację IController jako transient, czyli po prostu wszystkie kontrolery,
• wszystkie implementacje ModelValidatorProvidera jako transient, ale bez RootModelValidatorProvidera, gdyż wkroczylibyśmy potem w nieskończoną pętlę rozwiązywania zależności
• ProductDiscountCache jako Singleton
• CurrentUserProvider jako PerWebRequest

using System.Web.Mvc;
using Castle.MicroKernel.Registration;
using Castle.MicroKernel.SubSystems.Configuration;
using Castle.Windsor;
using WindsorLifeStyles.Services;

namespace WindsorLifeStyles
{
    public class WindsorInstaller : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            container.Register(
                Classes.FromThisAssembly()
                       .BasedOn<IController>()
                       .LifestyleTransient(),
                Classes.FromThisAssembly()
                       .Pick()
                       .If(typeof (ModelValidatorProvider).IsAssignableFrom)
                       .If(t => t != typeof (RootModelValidatorProvider))
                       .WithServices(typeof (ModelValidatorProvider))
                       .LifestyleTransient(),
                Component.For<ProductDiscountCache>()
                         .LifestyleSingleton(),
                Component.For<CurrentUserProvider>()
                         .LifestylePerWebRequest()
                );
        }
    }
}

Tworzymy własną implementację fabryki kontrolerów WindsorControllerFactory.cs opartą o Windsor Castla. Przedstawiam tutaj dosyć standardowe podejście do tematu:

using System;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
using Castle.MicroKernel;

namespace WindsorLifeStyles
{
    public class WindsorControllerFactory : DefaultControllerFactory
    {
        private readonly IKernel _kernel;

        public WindsorControllerFactory(IKernel kernel)
        {
            _kernel = kernel;
        }

        public override void ReleaseController(IController controller)
        {
            _kernel.ReleaseComponent(controller);
        }

        protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
        {
            if (controllerType == null)
            {
                throw new HttpException(404, string.Format("The controller for path '{0}' could not be found.", requestContext.HttpContext.Request.Path));
            }

            return (IController) _kernel.Resolve(controllerType);
        }
    }
}

No i wreszcie spięcie wszystkiego w  Global.asax.

using System.Web.Mvc;
using System.Web.Optimization;
using System.Web.Routing;
using Castle.Windsor;
using Castle.Windsor.Installer;

namespace WindsorLifeStyles
{
    public class MvcApplication : System.Web.HttpApplication
    {
        private static IWindsorContainer _container;

        private static void BootstrapContainer()
        {
            _container = new WindsorContainer().Install(FromAssembly.This());
            ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(_container.Kernel));
        }

        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();

            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);

            BootstrapContainer();

            ModelValidatorProviders.Providers.Clear();
            ModelValidatorProviders.Providers.Add(new RootModelValidatorProvider(_container.Kernel));
        }

        protected void Application_End()
        {
            _container.Dispose();
        }
    }
}

Uruchomienie aplikacji

Przy pierwszym wejściu na ekran pokazuje się formularz wprowadzania danych. Zauważmy, że w tym miejscu nie jest wołana walidacja, ani też odwołania do serwisów pobierających id użytkownika i dane z cache. Dlatego otrzymujemy wartości 1, 0, 0.

Dla danych czterech produktów o kodzie "AA" nie została udzielona zniżka. Przyjrzyjmy się liczbom wywołań poszczególnych komponentów: kontroler produktów został wywołany tylko raz, gdyż jego tryb życia to Transient. Z kolei ta sama instancja CurrentUserIdProvider została wywołana dwa razy, zgodnie z oczekiwaniami.

W ostatnim wywołaniu wprowadzamy celowo produkt, który może mieć zniżkę, ale niestety została przekroczona maksymalna liczba produktów, które można zakupić. Pojawił się komunikat walidacyjny. Zestawienie wywołań również jest zgodne z oczekiwanymi. Jedno wywołanie kontrolera (Transient), jedno wywołanie serwisu pobierającego id użytkownika oraz 3 wywołania odwołania do cache. Liczba odwołań do tego ostatniego serwisu będzie się zwiększać, co też jest potwierdzeniem stylu życia Singleton.

Podsumowanie

W tym wpisie przedstawiłem sposób w jaki można skonfigurować kontener Windsor Castle w prostej aplikacji MVC. Pokazałem na przykładzie jak ustawić style życia komponentów rejestrowanych w Castle dla Transient, PerWebRequest i Singleton. Ponad to wskazałem jak powiązać kontener z mechanizmem walidacyjnym ASP.NET MVC.  Najciekawszym jednak doświadczeniem było, to , że nie musiałem rejestrować handlera do obsługi lifestyla  PerWebRequest przez wpis konfiguracyjny w web.configu (tak jak sugeruje informacja na stronie Castla).

W tym wpisie przybliżę sposoby definiowania trybu życia komponentów w kontenerze Windsor Castle.

Tryby życia

W aplikacji możemy skonfigurować w ramach jakiego zakresu dany komponent ma żyć oraz kiedy ma zakończyć swój żywot. Windsor dostarcza kilka takich trybów z pudełka, a należą do nich:

• Singleton - czyli jedna instancja na całą aplikację,
• Transient - jedna instancja na każde wywołanie z kontenera,
• PerWebRequest - instancja jest współdzielona w ramach jednego web requesta aplikacji webowej,
• PerThread - instancja komponentu jest współdzielona w ramach jednego wątku,
• Pooled - zostanie stworzona pula obiektów, z której na żądanie jest pobierana jedna instancja,
• Custom  - można utworzyć własną definicję trybu życia instancji.

W 99 procentach korzysta się z pierwszych trzech, tj: Singleton, Transient oraz PerWebRequest. Pozostałych trybów życia instancji używa się sporadycznie.

Jeżeli nie zostanie wskazany tryb życia , to domyślnie Windsor Castle użyje trybu Singleton.

Przyjrzyjmy się zatem trybom życia z bliska, skupiając uwagę na trzech najczęściej używanych.

Singleton

Instancje pozyskiwane z kontenera o trybie życia Singleton są tworzone tylko raz w momencie gdy ktoś ich zażąda po raz pierwszy. Każde następne wywołanie powoduje uzyskanie tej samej instancji. Zniszczenie instancji o tybie życia Singleton nastąpi z chwilą zniszczenia instancji kontenera. Użycie metody container.Release()  nie da żadnego rezultatu. Dobrym powodem na ustawienie instacji jako Singleton jest:

• bezstanowość danej instancji lub
• możliwość posiadania stanu, ale niezmiennego przez cały cykl życia aplikacji.

W przypadku Singletonu należy zwrócić uwagę na pracę z komponentem w środowisku wielowątkowym.

Konfiguracja Singletonu w instalatorze przedstawia poniższy przykład:

// domyślny Lifestyle to Singleton
Register(Component.For<Car>());
// lub też explicite
Register(Component.For<Car>().LifestyleSingleton());

Transient

Instancje o cyklu życia Transient są przeciwieństwem instancji o cyklu życia Singleton. Nie są przywiązane do żadnego kontekstu, a zatem każdorazowo kiedy prosimy kontener o komponent,  otrzymujemy za każdym razem jego nową instancję.  Dobrym powodem użycia Transient jest przypadek w którym chcemy kontrolować czas życia instancji przy użyciu container.Release(). Dodatkowo, jeżeli nie jest to koniecznie, nie musimy dbać o ich bezpieczeństwo w środowisku wielowątkowym.

Register(Component.For<Car>().LifestyleTransient());

PerWebRequest

W koncepcji działania jest hybrydą pomiędzy Singletonem a Transientem. Instancja zarejestrowana w takim trybie zostanie utworzona gdy zapytamy o nią kontener po raz pierwszy w trakcie trwania web requestu. Każde kolejne prośba utworzenia kończy się zwróceniem przez kontener tej samej instancji. Próba wykonania Relase() na instancji zakończy się fiaskiem

Register(Component.For<Car>().LifestylePerWebRequest());

Według opisu na stronie Castla, ustawienie takiego trybu życia instancji wymaga konfiguracji w aplikacji webowej odpowiedniego modułu tj. Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule:

<httpModules>
   <add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.Windsor"/>
</httpModules>

Z kolei, jeżeli mamy do czynienia z IIS w wersji >= 7.0, wtedy musimy umieścić konfigurację w sekcji system.webServer/modules:

<configuration>
   <system.webServer>
      <modules>
         <add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.Windsor" />
      </modules>
   </system.webServer>
</configuration>

Przykładowa aplikacja

Przykładowa aplikacja webowa napisana w ASP.NET MVC zostanie przedstawiona w kolejnym wpisie.

Źródła

http://docs.castleproject.org/Windsor.LifeStyles.ashx

Value was either too large or too small for a UInt32.

Fortunately one of my collegues knew the answer how to fix it - just simply u need to save all documents. Nice.

/// <summary>
/// Adds all of the assembly"s embedded resources whose names end with <c>.hbm.xml</c>.
/// </summary>
/// <param name="assembly">The assembly.</param>
/// <returns>This configuration object.</returns>
public Configuration AddAssembly(Assembly assembly)
{
	IList resourceNames = GetAllHbmXmlResourceNames(assembly);
	if (resourceNames.Count == 0)
	{
		log.Warn("No mapped documents found in assembly: " + assembly.FullName);
	}
	foreach (var name in resourceNames)
	{
		AddResource(name, assembly);
	}
	return this;
}

private static IList GetAllHbmXmlResourceNames(Assembly assembly)
{
	var result = new List<string>();

	foreach (var resource in assembly.GetManifestResourceNames())
	{
		if (resource.EndsWith(".hbm.xml"))
		{
			result.Add(resource);
		}
	}

	return result;
}

The answer was clear: the mappings are added to the queue (see class MappingsQueue.cs) and processed one by one in the order they were enqueued. And the order depends of the internal implementation of the GetManifestResourceNames method. Unfortunately this boils down to know the implementation of the method from System.Reflection.RuntimeAssembly that is quite hard to decompile and investigate.

[SecurityCritical]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern string[] GetManifestResourceNames(RuntimeAssembly assembly);

However from experiments we found out that the order of returned resources depends on the order they are defined in the *.csproj file.

Special thanks to Grzegorz S. for taking part in our experiments.

This is the next post from the quesi-series of notes about NHibernate Proxies.

What is ProxyDummy?

In the first post I introduced generated class for MyProxyImpl class implementing IMyProxy interface. One of the interesting things here is ProxyDummy class the proxy is directly inheriting from:

public class INHibernateProxyProxy : ProxyDummy, INHibernateProxy, IMyProxy, ISerializable, IProxy

This class has no members. It is a some kind of marker class. I search for usages in the solution but there is neither strongly typed reference nor run-time.

public class ProxyDummy
{
	/* No Implementation */
}

However CreateUncachedProxyType of the ProxyFactory reveals some dark side power: we find short comment describing why we inherit from the ProxyDummy class. And this is something that is self-explanatory =].

// Use the proxy dummy as the base type 
// since we're not inheriting from any class type
System.Type parentType = baseType;
if (baseType.IsInterface)
{
	parentType = typeof (ProxyDummy);
	interfaces.Add(baseType);
}

I believe this is something that is somehow a legacy code. Why do we need to have a concrete class in a proxy? Maybe this was intended to use in the future?

What is IProxy and INHibernateProxy?

The first interface - IProxy is a part of the LinFu project and it has only internal meaning for the LinFu.DynamicProxy namespace. The interface is defined as follows:

namespace NHibernate.Proxy.DynamicProxy
{
	public interface IProxy
	{
		IInterceptor Interceptor { get; set; }
	}
}

As we can see there is only one member defined there - IInterceptor type that is more attractive for further investigations.

Now is the turn for INHibernateProxy interface:

namespace NHibernate.Proxy
{
	/// <summary>
	/// A marker interface so NHibernate can know if it is dealing with
	/// an object that is a Proxy. 
	/// </summary>
	/// <remarks>
	/// <para>
	/// This interface should not be implemented by anything other than
	/// the Dynamically generated Proxy.  If it is implemented by a class then
	/// NHibernate will think that class is a Proxy and will not work.
	/// </para> 
	/// <para>
	/// It has to be public scope because
	/// the Proxies are created in a separate DLL than NHibernate. 
	/// </para> 
	/// </remarks>
	public interface INHibernateProxy
	{
		/// <summary> Get the underlying lazy initialization handler. </summary>
		ILazyInitializer HibernateLazyInitializer { get;}
	}
}

As we see in the summary of the INHibernateProxy interface - it is a marker that is used by NHibernate  to recognize if it is dealing with a proxy instance. The IProxy works only for LinFu.DynamicProxy context. INHibernateProxy interface is being used through the whole NHibernate project. It is important to generate proxy type with this interface implemented to let NHibernate use this class as a proxy. Dynamically generated class had it implemented with IProxy:

[Serializable]
public class INHibernateProxyProxy : ProxyDummy, INHibernateProxy, IMyProxy, ISerializable, IProxy

This is end for now.

In the previous post I showed how simple proxy class was generated by proxy factory. Now it is time to find some answers to the questions I asked.

The suspicious name of the proxy class

We have a mapped class called MyProxyImpl and it implements an interface IMyProxy. The implementing proxy class name is INHibernateProxyProxy. This is strange and questionable. Let's investigate this and I will try answer the first question: Why it has such a strange name?

One thing that I should expand in the previous post is a mapping definition that is really important in understanding the way NHibernate maps a persistent class. In this particular case we have following mapping file defined:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
				   assembly="NHibernate.Test"
				   namespace="NHibernate.Test.DynamicProxyTests.InterfaceProxySerializationTests">
	<class name="MyProxyImpl" proxy="IMyProxy">
		<id	name="Id">
			<generator class="assigned" />
		</id>

		<property name="Name" />
	</class>
</hibernate-mapping>

The most interesting part is the line with proxy="IMyProxy". This line tells NHibernate that generated proxy will have to implement IMyProxy interface instead of inheriting from MyProxyImpl class.

Note that the MyProxyImpl has not a virtual members and the proxy can be instantiated without errors! The reason it still works is because Proxy type is not being generated on class basis but by explicit proxy interface implementation.

The definition of this mapping file is available under the http://nhforge.org/doc/nh/en/index.html#mapping-declaration-class. We have there an explanation:

proxy (optional): Specifies an interface to use for lazy initializing proxies. You may specify the name of the class itself.

Description tells nothing about the generated class name, so we need to go debug through the code to see how the class name is resolved.
The stack trace pointed at PocoEntityTuplizer and its behaviour during the building the proxy factory for specific class. The clue is that we have some set of the types (interfaces) that are used in the resulting proxy with the first type set to INhibernateProxy.

// determine all interfaces needed by the resulting proxy
var proxyInterfaces = new HashedSet {typeof (INHibernateProxy)};

So the resulting proxyInterfaces set will finally have two types of the interfaces: INHibernateProxy and the IMyProxy. This will affect of course the DefaultProxyFactory PostInstantiate method. As a result when calling GetProxy we will have to take the first interface type when the class is based on the explicit proxy interface:

object proxyInstance = IsClassProxy
    ? factory.CreateProxy(PersistentClass, initializer, Interfaces)
    : factory.CreateProxy(Interfaces[0], initializer, Interfaces);

The IsClassProxy tells if the mapped class should be used for generating the name of the proxy or we should use the first interface type that is always INHibernateProxy. So far so good. The mystery solved!

My opinion about the way we access the interface by getting Interfaces[0] is a little bit clumsy. Finally this is always INhibernateProxy, so why we are using here a reference to the first item in the interfaces array ? I should ask this question in the nh-dev group.

But this leads to other additional question. How this behaviour is handled if I have many similar mappings? So let's say that I 'm going to declare the similar types: MyProxyImpl2 class that implements IMyProxy2 interface. How this will work if I have the same type, assembly and module names ?
After some investigations I found that NHibernate is creating the same INHibernateProxyProxy type within the INHibernateProxyAssembly in current AppDomain for IMyProxy and IMyProxy2. It would not be anything special but we have really strange fact. According to DefineDynamicAssembly signature description the assembly identity should be unique among AppDomain. As I expected this is just simply hint not requirement, so here we can have two types with the same names in the assembly with the same name and with the module as well. When we check the currentDomain.GetAssemblies() in CreateUncachedProxyType of the ProxyFactory we get the types in one app domain:

[27]: {INHibernateProxyProxyAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null}
[28]: {ISymWrapper, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a}
[29]: {INHibernateProxyProxyAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null}

 It is worth to remember that NHibernate generates separate dynamic assembly with the generated type for each proxy type within one AppDomain.

Ok, let's have a cold beer for that, and see you soon in the next post.

This is a first post from series I plan to write about proxy feature in NHibernate. I would treat this as a notes and observation rather than a regular tutorial. I hope that you can find these quasi-posts series useful. I encourage you to make experiments with NHibernate!
The version I'am working with is 3.3.1.4000. The names here or in the next posts will refer to the test case names or types used there.

NHibernate Proxy at a glance

NHibernate provides enabled by default feature called lazy-loading. In a one word: this is a feature that allows to keep a non-loaded referenced entity or collection of entities attached to the entity you are working with and loading them on demand when it is necessary.

NHibernate was using separate dll for the proxy factory, but now it is included in the codebase . Default proxy factory is based on the LinFu.DynamicProxy. You can see it's customized implementation under NHibernate.Proxy.DynamicProxy namespace. It is still possible of course to use your own ProxyFactory implementation. This can be done via configuration.

Proxy

As I mentioned above the default implementation of the  proxy factory is based on LinFu.DynamicProxy. More about this proxy generator you can find on codeproject.  I would not like to dig in the implementation of the LinFu. Instead let's see the experimentation with the simple interface and it's implementation as a proxy class.

So, we have IMyProxy interface with Id and name properties and MyProxyImpl implementation. Let's see what is the output of dynamically generated type. In order to do so, go to ProxyFixture test and run the Proxy test case. You can define DEBUG constant in the NHibernate test project. Additionally change Save method body in the DefaultProxyAssemblyBuilder and choose right assembly name. The output was taken from .NET Reflector and some code was removed from the output for clarity.

public interface IMyProxy
{
	int Id { get; set; }
	string Name { get; set; }
}

public class MyProxyImpl: IMyProxy
{
	public int Id { get; set; }
	public string Id { get; set; }
}

And the mapping file that is the essential here is listed below as an *.hbm.xml mapping:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
				   assembly="NHibernate.Test"
				   namespace="NHibernate.Test.DynamicProxyTests.InterfaceProxySerializationTests">
	<class name="MyProxyImpl" proxy="IMyProxy">
		<id	name="Id">
			<generator class="assigned" />
		</id>

		<property name="Name" />
	</class>
</hibernate-mapping>

[Serializable]
public class INHibernateProxyProxy : ProxyDummy, INHibernateProxy, IMyProxy, ISerializable, IProxy
{
    // Fields
    private IInterceptor __interceptor;

    // Methods
    public INHibernateProxyProxy()
    {
    }

    public INHibernateProxyProxy(SerializationInfo info1, StreamingContext context) : this()
    {
        System.Type type = typeof(IInterceptor);
        this.__interceptor = (IInterceptor) info1.GetValue("__interceptor", type);
    }

    public override ILazyInitializer get_HibernateLazyInitializer()
    {
        if (this.Interceptor == null)
        {
            return this.HibernateLazyInitializer;
        }
        object[] args = new object[0];
        InvocationInfo info = new InvocationInfo(this, (MethodInfo) methodof(INHibernateProxy.get_HibernateLazyInitializer), null, new Type[0], args);
        args = info.Arguments;
        return (ILazyInitializer) this.Interceptor.Intercept(info);
    }

    public override int get_Id()
    {
        if (this.Interceptor == null)
        {
            return this.Id; // refers to IMyProxy.Id property
        }
        object[] args = new object[0];
        InvocationInfo info = new InvocationInfo(this, (MethodInfo) methodof(IMyProxy.get_Id), null, new Type[0], args);
        args = info.Arguments;
        return (int) this.Interceptor.Intercept(info);
    }

    public override void set_Id(int num1)
    {
        if (this.Interceptor == null)
        {
            this.Id = num1;
        }
        else
        {
            InvocationInfo info = new InvocationInfo(this, (MethodInfo) methodof(IMyProxy.set_Id), null, new Type[0], new object[] { num1 });
            this.Interceptor.Intercept(info);
            object[] arguments = info.Arguments;
        }
    }

    public override void GetObjectData(SerializationInfo info1, StreamingContext context)
    {
        info1.SetType(typeof(ProxyObjectReference));
        info1.AddValue("__interceptor", this.__interceptor);
        info1.AddValue("__baseType", "NHibernate.Proxy.INHibernateProxy, NHibernate, Version=3.3.1.4000, Culture=neutral, PublicKeyToken=null");
        info1.AddValue("__baseInterfaceCount", 2);
        info1.AddValue("__baseInterface0", "NHibernate.Proxy.INHibernateProxy, NHibernate, Version=3.3.1.4000, Culture=neutral, PublicKeyToken=null");
        info1.AddValue("__baseInterface1", "NHibernate.Test.DynamicProxyTests.InterfaceProxySerializationTests.IMyProxy, NHibernate.Test, Version=3.3.1.4000, Culture=neutral, PublicKeyToken=null");
    }

    public virtual IInterceptor NHibernate.Proxy.DynamicProxy.IProxy.Interceptor
    {
        get
        {
            return this.__interceptor;
        }
        set
        {
            this.__interceptor = value;
        }
    }
}

Let's list interesting things here that I will try to explain in the next posts:

• The name INHibernateProxyProxy is really controversial. Why proxy class has such a strange name ?
• The proxy inherits from ProxyDummy. What the heck is that ?
• Here are two interfaces IProxy and INHibernateProxy. What they are here for ?
• What is IInterceptor and how it is used in NHibernate?
• What is ILazyInitializer and how it works ?
• Finally, how this magic works that when I try to access Id the entity is not loaded but when I access other property, proxy tries to get value from DB (if there is no entity stored in session cache)?

WindsorCastle jest kontenerem wstrzykiwania zależności. Jest to jeden z kilku projektów http://www.castleproject.org/. W tym wpisie krótko opiszę w jaki sposób ten temat ugryźć (delikatnie).

Prosta aplikacja dla fanów motoryzacji

Poniższy przykład trochę naiwnie pokazuje użycie kontenera w aplikacji. W tym konkretnym przypadku chcemy stworzyć moduł bazowy dla producenta samochodów, który dostarcza standardowo wykonany samochód wyposażony w standardowy silnik. W aplikacji chcemy mieć możliwość modyfikacji zarówno pojazdu jak i silnika w zależności od zapotrzebowania lokalnego sprzedawcy. Pomiędzy pojazdem i silnikiem zachodzą jednak pewne zależności, a ściślej rzecz ujmując samochód umie współpracować z silnikiem poprzez znany interfejs, a silnik jest kluczowy podzespołem samochodu . To co będzie się działo w samym silniku zależy od realizacje jego wykonania. Dla przykładu samochód może posiadać silnik spalinowy, elektryczny, hybrydowy etc. Takie podejście w aplikacjach biznesowych jest często stosowane i nie powinno być zaskoczeniem.
W naszej aplikacji zdefiniowaliśmy interfejs ICar, a w zależności od konfiguracji kontenera chcemy podać do jego konstruktora jako zależność jakąś konkretną implementację interfejsu IEngine. Zwróćmy uwagę, że w definicji konstruktora typem przekazywanego parametru jest interfejs, a nie jego implementacja. W najprostszym przypadku mamy do czynienia tylko z jedną implementacją interfejsu ICar i IEngine. Ale może się zdarzyć, że dla różnych implementacji ICar chcemy wstrzyknąć różne implementacje interfejsu IEngine.

public interface IEngine
{
	int HorsePower { get; }
}

public class Engine : IEngine
{
	public int HorsePower
	{
		get
		{
			return 100;
		} 
	}
}

public interface ICar
{
	int GetPower();
}

public class Car : ICar
{
	private readonly IEngine _engine;

	public Car(IEngine engine)
	{
		_engine = engine;
	}

	public int GetPower()
	{
		return _engine.HorsePower;
	}
}

Logika klasy Car jest dosyć prosta w tym przypadku, ale równie dobrze można by zastosować bardziej skomplikowany algorytm. Co więcej, interfejs ICar zapewnia jedynie kontrakt, a zwracaną implementację interfejsu ICar można skonfigurować w kontenerze.

Byty w Castle Windsor

Castle w odniesieniu do powyższych interfejsów i klas wprowadza trzy pojęcia:

• serwis - jest to abstrakcyjny kontrakt opisujący spójną jednostkę funkcjonalności; innymi słowy w naszej aplikacji interfejsy ICar oraz IEngine są serwisami, gdyż definiują tylko kontrakt, jaki implementujące je klasy muszą spełnić. W przypadku interfejsu IEngine implementujące klasy muszą posiadać właściwość, która zwróci liczbę opisującą moc silnika.
• komponent - jest to nic innego jak realizacja serwisu, tj. konkretyzacja abstrakcji funkcjonalności. W całej aplikacji może istnieć wiele komponentów, np. silnik może być spalinowy lub hybrydowy. Od konfiguracji kontenera zależy jaki komponent zostanie zwrócony dla danego serwisu.
• zależność zachodzi wtedy jeżeli komponent zależy od innych serwisów. W aplikacji samochodowej zależnością dla komponentu Car jest interfejs IEngine wstrzykiwany przez konstruktor.

Istotnym elementem Castla są klasy rejestrujące serwisy i komponenety. Bez nich kontener nie wie jakich implementacji ma używać w określonym kontekście. Klasa instalatora musi implementować interfejs IWindsorInstaller. W module bazowym naszej aplikacji skonfigurujemy kontener w taki sposób, żeby dla serwisu ICar używał komponentu Car oraz analogicznie dla serwisu IEngine - Engine.

Aplikacja z lotu ptaka

Rozszerzymy więc naszą aplikację o kilka modułów “sprzedażowych” i sprawdzimy jak teraz się zachowa Castle. Schemat solution wraz z wylistowanymi plikami oraz zależności modułowymi są przedstawione na obrazkach poniżej.

W odniesieniu do zależności pomiędzy projektami, to wszystkie moduły muszą posiadać referencję do kontenera wstrzykiwania zależności.

Dodając zależności użyłem NuGet Package Managera ( jak widać na chwilę obecną aktualna wersja to 3.2.1):

Zweryfikujmy w jaki sposób kontener poradzi sobie z rozwiązywaniem zależności w module StandardSeller. Gdy WindsorContainer zostanie już zinstancjonowany, wskazujemy mu skąd ma pobrać rejestracje zależności. Użyta linijka FromAssembly.Containing<ICar> oznacza, że chcemy pobrać wszystkie rejestracje z assembly zawierające interfejs ICar (odkrywcze, co nie ?). Metoda Resolve zwraca aktualnie zarejestrowany komponent dla serwisu ICar. W ten oto sposób na konsoli otrzymamy wartość “100”.

public class CarFactoryWindsorInstaller : IWindsorInstaller

{
	public void Install(IWindsorContainer container, IConfigurationStore store)
	{
		container.Register(Component.For<ICar>().ImplementedBy<Car>());
		container.Register(Component.For<IEngine>().ImplementedBy<Engine>());
	}
}

class Program
{
	static void Main(string[] args)
	{
		var container = new WindsorContainer();
		container.Install(FromAssembly.Containing<ICar>());
		var car = container.Resolve<ICar>();
		Console.WriteLine(car.GetPower());
		Console.ReadKey();
		container.Dispose();
	}
}

W module “SportSeller” wymienimy samochód pozostawiając bez zmian zależność od IEngine. W implementacji SportCar różni się od zwykłego samochodu tym, że moc silnika jest dwa razy większa.

public class SportCar : ICar
{
	private readonly IEngine _engine;

	public SportCar(IEngine engine)
	{
		_engine = engine;
	}

	public int GetPower()
	{
		return _engine.HorsePower * 2;
	}
}
public class SportSellerWindsorInstaller: IWindsorInstaller
{
	public void Install(IWindsorContainer container, IConfigurationStore store)
	{
		container.Register(Component.For<ICar>().ImplementedBy<SportCar>().IsDefault());
	}
}

Warto zwrócić uwagę na dwa ważne szczegóły:

• konieczne jest poinformowanie Castla, że chcemy używać komponentów z projektu bazowego - CarFactoryWindsorInstaller oraz z modułu sprzedaży samochodów sportowych - SportSellerWindsorInstaller
• konieczne jest wskazanie, że to własnie klasa SportCar jest domyślnym kompontentem w tym zakresie rozwiązywania zależności tj. w module SportSeller. Realizujemy to poprzez użycie metody IsDefault(). Jeżeli metoda IsDefault() zostanie pominięta, Castle użyje pierwszego zarejestrowanego komponentu tj. Car.

Rezultatem wykonania programu będzie pokazanie na konsoli wartości “200”.

class Program
{
	static void Main(string[] args)
	{
		var container = new WindsorContainer();
		container.Install(new CarFactoryWindsorInstaller());
		container.Install(new SportSellerWindsorInstaller());            
		var car = container.Resolve<ICar>();
		Console.WriteLine(car.GetPower());
		Console.ReadKey();
		container.Dispose();
	}
}

Ostatnim modułem w naszej aplikacji jest moduł sprzedaży samochodów budżetowych - BudgetSeller. W tym przypadku mamy standardowy samochód, z tą różnicą, żę jego elementem składowym jest silnik budżetowy, którego moc jest dwa razy mniejsza nic standardowego silnika. Zwróćmy uwagę, że wskazujemy kontenerowi installator z modułu CarFactory oraz wszystkie rejestracje z aktualnego modułu - FromAssembly.This(). Rezultatem wykonania programu w tym module jest wynik 50.

public class BudgetEngine : IEngine
{
	public int HorsePower
	{
		get { return 50; }
	}
}

public class BudgetSellerWindsorInstaller : IWindsorInstaller
{
	public void Install(IWindsorContainer container, IConfigurationStore store)
	{
		container.Register(Component.For<IEngine>().ImplementedBy<BudgetEngine>().IsDefault());
	}
}

class Program
{
	static void Main(string[] args)
	{
		var container = new WindsorContainer();
		container.Install(new CarFactoryWindsorInstaller());
		container.Install(FromAssembly.This());
		var car = container.Resolve<ICar>();
		Console.WriteLine(car.GetPower());
		Console.ReadKey();
		container.Dispose();
	}
}

Podsumowanie

We wpisie przedstawiłem bardzo podstawowy zarys koncepcji w CastleWindsor oraz przykładową aplikację pokazującą w jaki sposób skonfigurować i używać tego kontenera.

Żródła

http://www.castleproject.org/projects/windsor/

http://docs.castleproject.org/Windsor.MainPage.ashx

http://docs.castleproject.org/Windsor.Screencasts-Podcasts.ashx