Model jest tylko strukturą – teza.

Aplikacja do obsługi maratonu rowerowego

Post na moim blog opisujący pokrótce „architekturę” Abstract nad model layer.

Synteza

Założeniem tej edycji było stworzenie aplikacji na lata, z możliwością rozszerzania funkcjonalności i wymiany komponentów.

Sercem systemu był projekt w którym znajdowała się warstwa abstrakcji i modelów.

Abstrakcje gromadziły logikę, były to zbiory interfejsów (kontraktów), które gromadziły się w obrębie pewnych kontekstów. Domen:

  • Email,
  • Marathon Office,
  • Participant Register,
  • Participant Result,
  • Register User,
  • Web Interface,
  • Reports,
  • Throw Exception

Dodatkowo w obrębie tego projektu były zgromadzone modele:

  • Mail_message_model,
  • Marathon_office_model,
  • Registration_Participant_Model,
  • Registration_User_Model,
  • Time_Tag_Participant

Modele stworzone zostały w oparciu Entity Framework, w bazie każdy z nich miał osobny schemat. Jedynie Marathon_Office_model nie był stworzony w oparciu o EF, gdyż tam z powodu braku czasu zastosowałem ADO.net i procedury składowane.

Interfejs użytkownika zbudowany był w oparciu ASP MVC kontrolery łączyły się z poszczególnymi interfejsami w zależności od rozwiązywanego kontekstu. Lista kontrolerów:

  • ParticipantController  ,
    • ResultsList ,
    • StartingList
  • RegistrationController,
    • Register (get i post),
    • AddGroup (get i post),
    • Info1,
    • Info2
  • RegistrationListUserController,
    • RegistrationList
  • ReportController,
    • ReportResult
  • RegistrationParticipantController,
    • AddPArticipant (get i post),
    • ParticipantRegister (get i post),
    • ListOfRegistering,
    • CertificateForParticipant
  • VerificationEmailController
    • VerificationNumber (get i post),

Powyżej lista kontrolerów i akcji z części webowej aplikacji, oprócz jej byłą jeszcze część desktopowa (aplikacja obsługująca czytniki RFID), która odpowiadała za pomiar czasu.

Te dwie aplikacje korzystały z tej samej bazy wystawionej na MS SQL ,  logika była podzielona między bazę a aplikacje (większość w aplikacji). W bazie zastosowałem shematy do rozdzielenia poszczególnych części logiki (po stronie bazy). EF widział je jako osobne źródła, a baza utrzymywała spójność.

Model

Model wraz z abstrakcjami w teorii był możliwy do przenoszenia, był w osobnym projekcie był nie zależny od pozostałych części.

Kontrolery

Czym są kontrolery w aplikacji do obsługi maratonu? ciężko stwierdzić, być może są definicje (rozwiązanie) interfejsów, co było by logicznie spójne z całością ale…. Właśnie zawsze jest ale, w tym przypadku klasy rozwiązujące logikę, łączą się z modelem poprzez interfejsy które rozwiązują(realizują). Interfejs narzuca dane wejściowe i wyjściowe, mówi co ma być zrobione ale nie mówi w jaki sposób, to jest pozostawione klasie rozwiązującej interfejs.

W moim przypadku kontrolerami nazwał bym część złożoną z klas rozwiązujących interfejsy, stało by to nie co w sprzeczności z definicją idealnych kontrolerów.

Widok

Widokiem w moim przypadku było (jest) projekt stworzony na podstawie ASP MVC, który ma w sobie widoki, kontrolery i model, tak jak wynika to z przyjętego schematu ASP MVC.  Dodatkowo w tej warstwie dołożony został kontener zależności (ninject).

Praktyka – Wnioski

W praktyce nie było tak „różowo”, kontrolery z ASP MVC zawierały trochę logiki, był jeden przypadek, że łączyły się bezpośrednio z modelem, pomijając warstwę kontrolerów. Testów okazało się za mało co skutkowało błędami, szczególnie widocznymi w weryfikacji email, na szczęście nikt nie zauważył ;-).

Z braku czasu musiałem również przenieść część logiki do bazy, procedury składowane, szybciej dla mnie było napisać coś w MS SQL-u niż w apce.

Kolejnym problemem który wynikł był rozjazd między stroną dostępną dla zawodników a stroną administracyjną. Była to ta sama aplikacja ale widok dla zawodników był  publisznięty wcześniej, a część administracyjna publikowana nigdy nie była tzn. te same źródło tylko do publikacji poszła wersja starsza, a kolejne wersje były dostępne tylko lokalnie (panel zarządzania aplikacją). Dzięki temu nie musiałem robić logowania do systemu ;-).

Podsumowanie

Aplikacja spełniła swoje oczekiwania i to jest najważniejsze, działała jak należy, kilka procesów zostało zautomatyzowanych (w przeciwieństwie do edycji poprzednich).

Podsumowując architekturę MVC na której oparłem moje rozwiązanie, myślę że ona daje nam pewne ramy i tylko od nas zależy jak je wypełnimy.

ASP .net MVC nadaje się do rozwiązania większości problemów (tyczy się to również innych implementacji MVC w innych językach) ale nie do wszystkich. Takie jest moje zdanie.

Co do tezy postawionej na początku posta. W przypadku aplikacji do maratonu nie dało się rozdzielić modelu od interfejsów, w przypadku Torfowiska jest to możliwe poprzez repozytoria.

Reasumując, wszystko zależy od  właściwego odkrycia procesów i ich zrozumienia.

P.S.

A gdzie torfowisko i architektura tego „ustrojstwa”? Cóż torfowisko nie jest pisane w oparciu o MVC, nie ma tam widoku, kontrolerów. Jest za to logika, testy (duużo testów), „ubogi” model , wystarczający do wykonania postawionych celów, brak jest widoku ale za to jest bogaty event storming.

Linki