Abstact And Model Layer  (Layer of the Abstract And Model, chyba tak powinno być)

Opis jednego z projektów wchodzącego w skład aplikacji do obsługi maratonu rowerowego.

W założeniu chciałem stworzyć aplikacje uniwersalną,  której głównym projektem (.Net solucja podzielona na projekty) będzie kontener na interfejsy oraz model, a całą reszta aplikacji będzie się łączyć z tym projektem za pomocą interfejsów (kontraktów).

W założeniu ideał, w rzeczywistości nie koniecznie.

Z powodu  dużej ilości klas, ilość interfejsów rosła w zastraszającym tempie, ciężko było się odnaleźć aczkolwiek każdy moduł miał własny plik. Dodatkowo model danych również musiał być w tej warstwie, intefejsy z niego korzystały. Z modelem również wiązał się pewien problem, który wynikł z powodu samego EntityFrameworka (poniekąd niezrozumienia go przeze mnie). Oprócz modelu w EF było też model zrobiony w ADO, co dla mnie czasami jest łatwiejsze niż EF.

Przykład kodu interfejsy modułu AParticipantRegister:

Kolejnym problemem tudzież wadą było nie do końca słuszne rozbicie na moduły, wydaje mi się, że niektóre moduły powinny mieć mniejszą odpowiedzialność, a sama solucja podzielona na więcej projektów (modułów).

Podział modułu (abstract and model layer)

Moduły:

  • AEmail  – interfejsy odpowiedzialne za moduł tworzenia  i wysyłania emaili
  • AMarathonOffice – biuro zawodów, te miejsce zostało rozbudowane i jego cześć trafiła do katalogu Marathon_Office_Model (ADO.net)
  • AParticipantRegister – rejestracja zawodników
  • AParticipantResult – wyniki zawodników
  • ARegistration__Users – to miał być moduł odpowiedzialny za logowanie administratora, pewene kroki zostały poczynione ale koniec końców prace zostały wstrzymane,
  • ATestData – generacja danych testowych
  • AThrowException – wyjątki
  • ATimeResult – ta abstrakcja zostało mocno ograniczona kosztem biura zawodów
  • AWebInterface – filtry w interfejsie (nie do końca przemyślane)
  • AGetRandomTableFromDatabase – nazwa sugerująca metodę, a w rzeczywistości jest to klasa abstrakcyjna

Modele:

  • Mail Message Model – model związany z emajlami
  • Marathon Office Model – model w oparciu o ADO, biuro zawodów
  • Registration Participant Model – EF z wykorzystaniem schematów (baza danych) rejestracja zawodników
  • Register User Model – EF (schema jak wyżej) logowanie administratora
  • Time Tag Participant – EF (schema) model odpowiedzialny za pomiar czasu i tagi (RFID tag)

Podsumowanie

Patrząc z perspektywy czasu i czasu poświęconego na implementacje, podział na moduły nie był zły ale sposób podziału, odpowiedzialności modułów, były niewłaściwe. Wydaje mi się, że zabrakło dobrego rozeznania dziedziny problemu. Pracowałem szósty raz nad tą aplikacją ale nigdy nie była ona dobrze zaprojektowana, pokazała to sesja event stormingu, którą sam próbowałem zrobić. To akurat nie skończyło się zadowalającym wynikiem. Kolejną próbę podjąłem z kolegą ale również utknęliśmy w martwym punkcie, jest szansa że wyjdziemy z impasu bo są nowe osoby chętne do zmierzenia się z problemem maratonu na ścianie.

Dodatkowo jakość kodu spadał bo w końcowej fazie (przed startem) musiałem wybrać albo „dowiozę” kod gorszej jakości albo lepszej nie w pełni funkcjonalny. Wybrałem opcje numer jeden co widać w kontrolerze odpowiedzialnym za biuro zawodów tj. tzw. Fat Controller (tłusty kontroler).

Czas i świadomość, że aplikacja po dziesiątej edycji zostanie definitywnie zamknięta sprawił, że w końcowej fazie projektu jego jakość spadła.

Ostatecznie system zadziałał spełnił założenia ale sądzę, że jego rozwój z powodu powyższych niedociągnięć stał by pod dużym znakiem zapytania.

Kategorie: Archiwum