NeatCQRSLite raport 1 – dynamicznie generyczne generyki

14 komitów, 3 projekty i zaimplementowany cały CQRS (prawie cały :), świetny wynik jak na tydzień pracy.

Projekt

Na chwilę obecną są tylko 3 projekty w rozwiązaniu. Jest tam obecnie infrastruktura szyn CQRS i markery na oznaczenie agregatów. Docelowo interfejsy-markery do oznaczania agregatów i zdarzeń domenowych będą w osobnym projekcie, dzięki temu użytkownik nie będzie dołączał do projektu z obiektami domenowymi paczek nuget z implementacją logiką CQRS. Obecne projekty reprezentują się tak:

CQRSLite.Contract

Jest to kontrakt pomiędzy użytkownikiem a frameworkiem. Zawiera interfejsy szyn komend, zapytań i zdarzeń, zawiera również interfejsy dzięki którym użytkownik będzie mógł oznaczać swoje klasy między innymi: komendy, walidatory komend i handlery komend. Dzięki kontraktowi komponenty docelowego rozwiązania nie będą musiały znać implementacji CQRS, a podmiana implementacji szyn będzie się wiązała tylko z wymianą paczek Nuget lub zaimplementowaniu na własną rękę odpowiednich interfejsów.

CQRSLite.CQRS

Projekt zawiera implementację szyn komend, zapytań i zdarzeń. Podczas implementacji pojawiło się kilka problemów, pierwszym z nich jest problem inicjalizacji handlerów komend, oczywiście takie klasy powinny zostać zaimplementowane poprzez kontener DI, lecz nie możemy takiej klasy przekazać podczas inicjalizacji szyny komend, ponieważ zapotrzebowanie na odpowiedni handler jest dynamiczne i zależy od tego jaka komenda została wrzucona na szynę. Do tej pory pory w projektach używałem serwis lokatora, który w statycznej klasie umożliwiał dostęp do kontenera DI <ding> <ding> shame shame <ding> <ding>. Podczas implementacji frameworku jednak wykorzystałem sposób zaprezentowany przez Macieja Aniserowicza, czyli przekazywaniu przez konstruktor funkcji, która pozwala pozwala pobrać odpowiednią klasę z kontenera DI. Zalety? Brak ochydnego serwis lokatora, lepsze testowanie. Analogiczne rozwiązanie zostało zastosowane przy szynach zapytań i zdarzeniach.

Kolejnym problemem, który stanął mi na drodze do wymarzonego frameworku, są generyki, o ile fajnie się z nich korzysta i można przy ich pomocy ładnie pooznaczać klasy zapytań i handlerów, dzięki temu handler<A> obsługuje tylko zapytanie A, jednak cała at fajność gdzieś ma swoje kruczki. Jednym rozwiązaniem jest dołożenie dodatkowych typów generycznych do sygnatury metody, jednak wtedy C# nie będzie mógł się domyślić obu typów generycznych i trzeba będzie zawsze podawać je w <~> , co nie jest fajnym rozwiązaniem. Drugim, według mnie przyjemniejszym dla końcowego użytkownika jest używanie typu dynamic, dzięki temu C# zaczyna działać trochę jak JavaScript, i nie patrzy że w trakcie kompilacji typy nie zgadzają się, dopiero w trakcie działania programu sprawdza na obiekcie czy posiada on odpowiednią funkcję, która może się wykonać z takim argumentem.

CQRSLite.CQRS.Tests

Ostatnim projektem jest testami implementacji CQRS. Testy są napisane z użyciem biblioteki xUnit i NSubstitute. Niestety w swojej krótkiej karierze programisty nie nauczyłem się podejścia TDD, dlatego najpierw piszę kod, a później jest on testowany (o ile w ogóle <ding> shame …) i był bym wdzięczy jak zostawicie w komentarzach namiary na ciekawe materiały o TDD.

Roadmap

W tym tygodniu zamierzam walczyć z:

  • Pakowaniem projektu do paczek Nuget
  • Ogarnięciem środowiska CI
  • Automatyzacją pakowania i publikowania paczek na serwis nuget.org
  • (opcjonalnie) stworzeniem wiki z opisem instalacji i używania frameworku
  • (opcjonalnie) refaktoryzacją starego projektu opartego na CQRS, aby mieć realne doświadczenia jak współpracuję się z frameworkiem

 

One Pingback/Trackback

    14 March 2017 at 10:03am
    NeatCQRSLite raport 1 – dynamiczno generyczne generyki – ...
  • dotnetomaniak.pl