Zmiana architektury maratonu zakończyła się.  Testy przeszły pozytywnie, unit testów nie mam (uczę się). Poklikałem po aplikacji zarejestrowałem się wiele razy, mejle przychodzą poprawnie, rejestracja odbywa się bez problemu.

Kod znajduje się na githubie Maraton Abstrakcja.

Po zakończeniu tego etapu mam aplikację w której istnieje projekt posiadający interfejsy i modele danych zbudowanych w oparciu o Entity Frameworka oraz modele dodatkowe. Interfejsy są w plikach których nazwa sugeruje do jakiej części aplikacji się odnoszą, analogicznie modele. Projekty składające się na solucje:

  1. Abstact_And_Model_Layer
  2. DataBaseRegistration
  3. LibDataBase
  4. ModelParticipants
  5. Reports
  6. SendMail
  7. ThrowException
  8. maratonMszna_v4

Konwencji nazw nie utrzymałem jest tu pewien bałagan.

1. Abstact_And_Model_Layer – projekt z warstwą abstrakcji czyli z plikami interfejsów przyjąłem że każdy plik w którym są interfejsy zaczyna się od dużej litery „Anazwapliku”, modele są w osobnych katalogach oznaczających przeznaczenie,  w tych katalogach są również  klasy z dodatkowymi modelami, które jak np. w przypadku rejestracji zawodnika mają zadeklarowane „pola wymagane” (Requqried, DataAnonations).

2. DataBaseRegistration – projekt  opisujący metody rejestracji i logowania użytkownika do aplikacji maraton.

3. LibDatabase – projekt opisuje rejestrację zawodnika w systemie, generację numeru weryfikacyjnego, pola filtrów, metody do generacji danych testowych (fragment używany w pierwszej fazie projektowania gdy nie było jeszcze rzeczywistych danych testowych), według pewnej zasady nadmiarowy kod szkodzi tu jednak zdecydowałem się na pozostawienie metod w aplikacji, uznając że są na tyle odseparowane od reszty że nie będą „przeszkadzać”.

4.ModelParticipants – projekt opisuje metody związane z zawodnikiem tj. przypisanie tagu (dyskietka), wyświetlenie czasu zawodnika, wyniku, tworzenie list startowych.

5.Reports – jak sama nazwa wskazuje przygotowanie raportów, definicje raportów znajdują się w projekcie z kontrolerami i widokami,  a w tym projekcie są generowane raporty.

6.SendMail – projekt odpowiedzialny za wysyłanie i przygotowanie mejli między innymi potwierdzenie rejestracji, weryfikacja rejestracji itp.

7.ThrowException – projekt z dodatkowymi wyjątkami – nie wszedł do warstwy abstrakcji,  aczkolwiek jest do tego gotowy.

8.maratonMszana_v4 – główna część aplikacji zawierająca kontrolery i widoki, dodatkowo zawiera metody związane z filtrem w liście zarejestrowanych zawodników.

Podsumowując pracy było bardzo dużo, kilka razy musiałem zaczynać na nowo. Pytanie czy to ma sens muszę pozostawić otwarte. Na pewno dzięki temu jest większy porządek, modele i interfejsy są w jednym projekcie, poszczególne części aplikacji nie widzą się nawzajem, a potrzebne metody czy dane czerpią z warstwy abstrakcji (Abstact_And_Model_Layer).

Moim celem było oddzielenie (fizyczne) interfejsów i modeli od reszty i to się udało czas pokarze czy przyniesie to jakieś wymierne korzyści, a na razie  były owocne ćwiczenia.