Architekutra Maratonu nie co uległa zmianie, od wersji pierwszej ewolucja kodu, rozpoczęła się. Teraz jest wersja piąta, która ewoluuje częściej niż pozostałe razem wzięte.

Cel jaki przyświecał mi w tej wersji to stworzenie ideału (szklane domy, utopia itd…), jak wiadomo ideał nie istnieje ale co za problem żebyśmy do nie go dążyli.

Krok pierwszy.

Postanowiłem że aplikacja podzielona będzie na moduły ze względu na funkcjonalność (logikę biznesową, mądre słowo ;-), dodatkowym profitem z tego tytułu będzie porządek, oprócz tego na czytałe msię o wzorcu repozytorium chciałem go wykorzystać. Repozytorium ma być warstwą pomiędzy aplikacją a bazą, stworzyłem coś takiego w  osobnym projekcie, bazę miałem stworzoną, preferuje podejście Base First, dorzuciłem Entity Frameworka za modelowałem część tabel odnoszących się do rejestracji zawodnika w maratonie i wysyłania mejla z numerem i potwierdzeniem rejestracji. Reszta aplikacji korzystająca z tego modułu nie używa kontekstu EF-a a jedynie interfejsy. Wiedziałem że będę korzystał z odwrócenia zależności i z kontenera (Ninject) więc musiałem od samego początku budować odpowiednio klasy.

Maraton jest budowany w  oparciu o MVC z tym, że uznałem (po przeczytaniu kilku artykułów) będzie to nie co bardziej „rozproszone”, fizycznie  model w osobnym projekcie, kontrolery minimalistyczne, widoki standardowo.

Początkowa (funkcjonalna) wersja maratonu miała moduły

  • z modelem bazy,
  • z kontrolerami i widokami,
  • z obsługą mejli
  • z dodatkową obsługą błędów
  • z testami

Całość była tworzona w Frameworku 4.0.

Krok Drugi

W tym kroku chciałem rozbudować aplikację o moduł logowania do panelu administracyjnego ale koniec końców praca ugrzęzła w martwym punkcie aczkolwiek moduł powstał oraz dodatkowym moduł z modelem, w bazie wykorzystałem dodatkową scheme dzięki temu EF-widział to jako „osobny byt”.

Krok Trzeci

Podniesieni wersji Frameworka do 4.5.2, to udało mi się zrobić za piątym razem usunąłem moduł z testami (za dużo zależności).

Krok Czwarty

Dodałem moduł z raportami ale tutaj pojawił się pierwszy zgrzyt nie co nie zrozumiały, definicje raportów trzymane są w  module kontrolerów, inaczej moduł tworzący raporty (posiadający funkcje generacji) nie widział definicji raportów.

Krok Piąty

Ogarnęła mnie myśl stworzenia aplikacji która będzie posiadała warstwę abstrakcji między modułem kontrolerów i widoków a dodatkowymi modułami, czyli moduł z interfejsami i modelami. Dlaczego? Dzięki zastosowaniu interfejsów mogę nie tylko rozdzielić projekty (wydzielić warstwę abstrakcji) ale również będę mógł (przynajmniej tak słyszałem) podmienić klasy, które dziedziczą po interfejsach w dowolnym momencie życia aplikacji. Inna sprawa czy miało by to sens nie koniecznie ale jak jest możliwość poćwiczenia to czemu nie spróbować. Kolejna kwestia związana z tym tematem jest taka, że jeszcze mi się nie udało przenieść wszystkich interfejsów, na razie generuje to dużo błędów i tak jak kiedyś przy refaktoryzacji popełniłem błąd robiąc za dużo zmian naraz tak teraz przy wymianie interfejsów popełniłem ten sam błąd ponownie. Najważniejsze przy takiej robocie to praca małymi krokami.

Podsumowanie

Na tę chwile nie spodziewam się już zmian większych w architekturze (chyba że pójdę w CQRS) muszę nie co nadgonić z kodem, tworzę kolejny moduł odnośnie rejestracji czasu (tu mogła by być dodatkowa baza CQRS ideał ;-), myślę że pójdę raczej w unit testy (kod jest gotowy  do zastosowania testów).