IRegistrationModule - porządki w kontenerze

6 Maja 2016

Jakiś czas temu pisałem o DI i IoC oraz o tym, że będę używał kontenera do automatycznego ładowania wielu modułów podczas startu aplikacji. Początkowo zrobiłem metodę ContainerWrapper.AutoRegister(), która iterowała po wszystkich bibliotekach związanych z SharpOfficem i rejestrowała odpowiednie klasy. Ale było to dość zagmatwane, więc postanowiłem trochę to uprzątnąć.

Po pierwsze dużą niewygodą było trzymanie implementacji wielu niezbędnych interfejsów w oddzielnym projekcie (SharpOffice.Common). Myślałem, że będzie to dobre rozwiązanie, ponieważ widziałem taki podział w innych projektach, ale stanowiło przeszkodę ponieważ ContainerWrapper siedzi w SharpOffice.Core, a dwa projekty nie mogą się wzajemnie do siebie odwoływać. Także przeniosłem wszystkie klasy do SharpOffice.Core/Common/ zachowując namespace SharpOffice.Common.

Następnie utworzyłem interfejs IRegistrationModule

public interface IRegistrationModule
{
	void Register(DryIoc.Container container);
}

Oraz przepisałem wszystkie metody na klasy implementujące ten interfejs. Jeszcze będę musiał odpowiedzieć sobie na bardzo ważne pytanie: czy powinienem automatycznie ładować wszystko czy robić więcej modułów i ich tworzenie zostawić użytkownikowi (t.j. osobie tworzącą bibliotekę z aplikacją/pluginem).

Dotychczasowy SharpOffice.Core/ContainerWrapper.cs.

Nowy wygląd: SharpOffice.Core/Container/.

Ponieważ niektóre moduły ładują wiele typów naraz i chcą obiektów typu Assembly w konstruktorze, musiałem dodać specjalne warunki przy tworzeniu ich przez Activator.CreateInstance(). Znówże, jeśli postanowię bardziej robić moje moduły, to ten problem zniknie.