DI: użycie Autofac

Z poprzedniego posta “DI: profesjonalne kontenery” wiemy, że wykorzystujemy kontener. A także, że użycie własnej implementacji to głupota. Pomyśleliśmy również jakimi nad kryteriami wyboru kontenera do naszego projektu.

Tak jak napisałem: ja używam Autofac. I właśnie ta biblioteka wyląduje w przedstawianym demo.

Pierwsze co robię to:

Install-Package Autofac

Mając na pokładzie Autofaca mogę z niego korzystać, zapominając o swoim PoorMansContainer. Autofac jest o tyle ciekawy, że bardzo mocno separuje dwie “fazy” działania kontenera: konfigurację i dostarczanie instancji. Separuje je tak mocno, że do konfiguracji wykorzystuje się osobną, dedykowaną klasę: ContainerBuilder. Konfiguracja w omawianym demie wygląda tak:

static void Main()
{
 var builder = new ContainerBuilder();
 Assembly executingAssembly = Assembly.GetExecutingAssembly();

 builder.RegisterAssemblyTypes(executingAssembly)
 .AsSelf()
 .AsImplementedInterfaces();

 // override default registration if needed
 builder.RegisterType<EmailValidator>()
 .AsImplementedInterfaces()
 .SingleInstance();

 _container = builder.Build();
}

https://github.com/maniserowicz/di-talk/blob/demo5-start/src/app/WebServer.cs

Widzimy tutaj dwie opcje, których nie posiadał mój własny kontener: automatyczną rejestrację wszystkich klas w aktualnym assembly (RegisterAssemblyTypes) oraz konfigurację EmailValidatora jako Singleton. Proste? Proste. A jakie potężne.

Dodatkowo Autofac oczywiście potrafi po sobie posprzątać:

static void Shutdown()
{
_container.Dispose();
}

A jak wygląda tworzenie kontrolera? O dziwo, identycznie jak u mnie!

public void RegisterUser(string email)
{
 var controller = _container.Resolve<UsersController>();

 controller.RegisterUser(email);
}

Ba, mało tego! Nigdzie indziej w całej aplikacji nie zmieniło się NIC! To dzięki zastosowaniu się do “3 calls pattern”, o którym już pisałem (i o którym jeszcze napiszę). Aplikacja ma głęboko gdzieś czy jej kontrolery są rzeźbione mymi rencami pienknymi, czy też przez kontener tworzone “like a pro”.

Oczywiście to co zobaczyliśmy wyżej to jedynie romantyczne liźnięcie możliwości Autofaca samym czubem ozora. Potrafi on o wiele więcej, na przykład rozbić konfigurację kontenera na osobne, “reużywalne” klasy (moduły). Wspiera też interceptory, dzięki czemu możemy pobawić się w AOP bez “tkania” kodu (code weaving) na etapie kompilacji. Ładnie integruje się też na przykład z ASP.NET MVC i kilkoma innymi frameworkami. Ale nie ma sensu, abym to wszystko przepisywał i tłumaczył z angielskiego, odsyłam do bardzo dobrej dokumentacji: https://github.com/autofac/Autofac/wiki.

Jeszcze jedno małe wtrącenie na koniec: na jednym z moich występów zwrócono mi uwagę, że nie mówi się “ałtofak” tylko “ałtofejk”. Nie mogłem wprost w to uwierzyć, więc zapytałem autora, Nicholasa. Okazało się, że przez cały czas mówiłem poprawnie. Żeby jednak nie było wątpliwości i aby poprawna wymowa utkwiła w pamięci narysowałem kalambur utrwalający ten jakże potrzebny w cywilizowanym świecie fakt:

To tyle jeśli chodzi o Autofac. Wiem, przedstawiłem bardzo podstawowe jego zastosowanie, ale być może w przyszłości urodzi się coś bardziej zaawansowanego. Póki co: do następnego razu, kiedy to nadejdzie pora na kilka finalnych refleksji!