OpenNETCF.IoC – pierwsze kroki

Jak się okazuje, elementy używane w czasie tworzenia aplikacji pod OpenNETCF.IoC niewiele różnią się od tradycyjnych elementów używanych w aplikacjach opartych na Smart Client Software Factories ( na szczęście nie ma tu ‘automatów’ generujących tony kodu  jak z karabinu maszynowego). W końcu OpenNETCF.IoC bazuje na MCSF, które z kolei bazowało na SCSF. Więc jeżeli ktoś wcześniej ich używał, powinien mieć zadanie ułatwione 🙂

Generalnie, OpenNETCF.IoC pozwalają na stworzenie aplikacji opartej o moduły, które można dynamicznie dołączać do głównej aplikacji przy wykorzystaniu Inversion of Control i Dependency Injection.

W samym frameworku nie zabraknie nam takich znajomych terminów jak WorkItem, SmartPart, Item, Service itp. Ale po kolei… bo przecież nie każdy mógł mieć z nimi do czynienia, a pisząc aplikację fajnie by było *czuć* co się używa… (pozwolę sobie się miejscami oprzeć o publikację “Designing Smart Clients Based on CAB and SCSF” opisanych przez Mario Szpuszta – gdyż sam kod udostępniony na codeplexie, niestety nie zawiera zbyt wielu komentarzy).

W aplikacji, będziemy mieli dostęp do czegoś co się nazywa WorkItem – będzie to taki nasz pojemnik na obiekty używane przez program, które wymagane są do wykonania jakiegoś zadania. Będziemy mieli również jeden obiekt RootWorkItem – który jest takim pojemnikiem, trzymającym kolekcje WorkItemów, Itemów, Servisów itd.
Itemem – jest dowolna instancja o unikalnej nazwie (np.  jakiś widok – WelcomeView); możemy mieć wiele takich instancji, pod warunkiem, że  każda z nich będzie miała unikalną nazwę.
Service – jest dość podobny do Item’u, z tą różnicą, że możemy mieć tylko jedną instancję danego typu.

Rejestracja dowolnego item’u w RootWorkItem‘ie odbywa się w sposób następujący:

Tworzenie naszej aplikacji, zaczynamy od utworzenia głównego okna aplikacji (tzw. Shell), które będzie odpowiedzialne za dynamiczne ładowanie modułów i widoków aplikacji. W tym celu, modyfikujemy klasę Program, aby implementowała klasę abstrakcyjną SmartClientApplication wskazując jej nasz główny formularz:

W samym zaś głównym oknie, definiujemy Workspace’y (coś jak content holder w ASP.NET), w których będą wyświetlane widoki (OpenNETCF.IoC pozwala nam na użycie już zdefiniowanego Workspace’a, TabWorkspace’a oraz DeckWorkspace’a).

Widoki – to tak naprawdę kontrolki użytkownika implementujące jeden wspólny interfejs – ISmartPart, tworzone w celu wyświetlenia informacji użytkownikowi tudzież zebraniu jakichś informacji od niego.

Poniżej prosty kawałek kodu, głównego kontenera – ShellForm – który na starcie wyświetli użytkownikowi widok “WelcomeView“:

Kto używał SCSF ten wie, że na starcie generował nam parę projektów (Shell, Infrastructure.Interface, Infrastructure.Layout, Infrastructure.Library, Infrastructure.Module), co pozwalało na odseparowanie różnych funkcjonalności od siebie. W przypadku OpenNETCF.IoC – również wygodnie byłoby utworzyć sobie podobną strukturę.

Na pewno, fajnie byłoby posiadać projekt “Shell” – zawierający główny formularz aplikacji.  W “Infrastructure.Interface” moglibyśmy przetrzymywać interfejsy dla prostych serwisów używanych przez naszą aplikację jak i nazwy stałych, takie jak unikalne nazwy Itemów, Widoków itp.

Funkcjonalności naszej aplikacji, możemy podzielić na różne grupy, które z kolei możemy dodać do naszej aplikacji jako oddzielne moduły. Każdy z nich, powinien posiadać klasę główną, która będzie implementować klasę abstrakcyjną ModuleInit odpowiedzialną za ładowanie workitemów oraz serwisów dla danego modułu. Ładowanie, modułu odbywa się dzięki dodaniu pliku xml w projekcie Shell – ProfileCatalog.xml – definiującego, który moduł powinien zostać załadowany przez aplikację podczas startu. Przykładowa zawartość takiego pliku, znajduje sie poniżej:

I to by było póki co na tyle… wydaje mi się, że koło zostało znalezione… aplikacja powstanie w oparciu o framework OpenNETCF.IoC.  Co dziwne – o ile nie polubiłem się z SCSF, o tyle całkiem przyjemnie tworzyło mi się szkielet aplikacji w jego dalekim, odchudzonym kuzynie 🙂