W końcu dotarłem do ostatniej wersji aplikacji do obsługi maratonu rowerowego, nad którą spędziłem najwięcej czasu i „straciłem” najwięcej energii. Najwięcej też zyskałem wiedzy i świadomości jak powinna być zbudowana aplikacja. Nie Maraton (moja aplikacja, Maraton to skrót z którego będę korzystał w dalszej części), w założeniach miał być dobrą aplikacja ale nie udało się tego dokonać i sądzę że to z powodu niedostatecznie dobrze przeprowadzonej fazy projektowania. Uwidoczniła to sesja z Event Stormingu, którą wspólnie z kolegą przeprowadziliśmy, a którą kontynuować będziemy w szerszym gronie. Bo aplikacja w moich oczach nie należy do udanych ale posłuży za przykład w Event Stormingu.

Planuję, że ten artykuł zapoczątkuje serie o ostatniej wersji aplikacji do obsługi maratonu rowerowego. Będę przybliżał tę wersje sposób jej uruchomienia i jej budowę (w skrócie).  O architekturze wspominałem ,  a tu chciałem  zawrzeć pewne wnioski, które urodziły się podczas ostatnich tygodni pracy nad aplikacją i wspomnieć o finale czyli o użyciu „na produkcji”.

Powyżej link do ostatniej wersji. Na razie tylko kod później będą też skrypty, bo jak wiadomo (albo i nie), ja dzielę logikę między baza i aplikacje. Sposób w ostatnich czasach mało popularny, teraz jest modne żeby aplikacja miała całą logikę a baza to tylko magazyn danych. Ja uważam, że logika powinna być podzielona między aplikacje i bazę ale to tak jak w życiu bywa to zależy, to zależy od kontekstu.

Powodem powstania zupełnie nowej wersji, była wtopa przy poprzedniej, która i tak była dwa lata (druga wersja była tylko lekko zmodyfikowana). Zawierała sporo błędów i niedociągnięć największą bolączką było to, że wiele zadań trzeba było rozwiązywać przez managmenta z ms sql-a, co było dosyć kłopotliwe, każdy wie, że grzebanie w bazie generuje problemy w dłuższej perspektywie. Kolejną wadą była zbyt duża rejestracja i brak prawdziwej weryfikacji adresu email oraz wielokrotna rejestracja tych samych zawodników. Do wad również należała za duża ilość aplikacji, były cztery.

Powyższe powody w głównej mierze zaważyły nad stworzeniem programu od początku i dopiero w trakcie jego tworzenia następowały większe zmiany czyli przejście z Frameworka 4.0 na 4.5.2, oraz zmiana architektury z jednego repozytorium na wydzielenie całego modułu z warstwą abstrakcji (interfejsy) oraz modelem i podział aplikacji na moduły, które w założeniu miały być osobnymi bytami w aplikacji miały być podzielone ze względu na wykonywane działania „byznesowe”.

W teorii brzmiało dobrze w rzeczywistości nie koniecznie.