W celu nauki Angulara 2 i Springa tworzę po godzinach aplikację wspomagającą proces szkolenia kolarzy. Założenia tej aplikacji są następujące:
Administrator
- Zarządza klubem (klubami), zawodnikami i trenerami
- Zarządza programami szkoleniowymi i ćwiczeniami
- Może wszystko
Trener
- Tworzy indywidualne plany treningowe dla zawodników
- Tworzy szablony planów treningowych i wprowadza ćwiczenia
- Akceptuje lub odrzuca sugestie zawodników, widzi ich sesje treningowe
Zawodnik
- Wprowadza sesje treningowe ze szczegółami
- Widzi swój plan ułożony przez trenera i przypisuje treningi
- Czyta i pisze prywatne wiadomości do trenera lub do zespołu
Czy tworzyć 3 osobne encje Admin, Coach, Cyclist? Zalet jest kilka:
- Tak będzie czytelniej w kodzie. Wiemy, kto jest kim.
- Powyższe encje mają swoje oddzielne pola.
Ale jest też kilka wad:
- Wszyscy muszą się jakoś logować - login, hasło, cokolwiek
- Mają też wiele innych wspólnych cech - trzeba dublować pola
Polimorfizm? Stworzyć klasę User, a po niej dziedziczyliby Admin, Coach, Cyclist. Czy takie rozwiązanie jest idealne? A jeśli trener lub admin będzie jednocześnie zawodnikiem? Oczywiście mogą mieć osobne konta, ale to też nie jest takie wygodne. Nawet gdyby zastosować polimorfizm i rzutować z User na Admin w razie potrzeby, czy można wymusić, żeby User nie dał się zrzutować, jeśli nie będzie adminem (czyli np. miał user.type==UserType.ADMIN)?
Chcę wprowadzić pewną innowację, czyli zespoły oparte o SCRUM, więc każdy sobie będzie trenerem, a nad wszystkimi będzie czuwał lider grupy. Tutaj sytuacja się komplikuje.
Jaka architektura będzie najlepsza jeśli chodzi o klasy DTO w Javie i encje w bazie? Prawdopodobnie wykorzystam ORM-a wbudowanego w Springa do obsługi bazy danych.