MVC z aktywnym modelem - diagram klas

Witam !
Mam do zaprojektowania aplikację, którą możemy podzielić właściwie na dwie "podaplikacje": pierwsza do obsługi klienta, a druga przeznaczona do pewnych operacji dla pracowników. Generalnie chciałem to zaprojektować, korzystając z MVC z aktywnym modelem, więc wykombinowałem sobie dość trywialne podejście, że dla każdego przypadku będzie jeden model,widok i kontroler. Prosiłbym o ocenienie prawidłowości mojego diagramu klas (oczywiście jeszcze niedokończonego) oraz w ogóle samą koncepcję. Diagram w załączniku.

EDIT:
Pytania, które zapomniałem zadać:

1. Jeśli w przypadku, gdy dany pracownik obsługujący daną aplikację powinien mieć możliwość przejścia z jednej "podaplikacji" do drugiej, to powinienem w kontrolerze zrobić metodę do przekazania sterowania innemu kontrolerowi ?
2. Czy model powinien mieć metodę dodającą jakby obserwatora dla danego widoku ?

EDIT - 14.12.2016, 21:38
Aktualizacja jpg zawierającego MVC oraz dodanie jpg z logiką biznesową dotyczącą obsługi klienta

Bardzo ogólna rada. Spal i zakop ten diagram - cokolwiek by to nie było. Wypij coś - tak żeby Ci z głowy wyleciało.
I spisz co ta aplikacja ma robić - i to zacznij projektować. To nie tak, że projekt jest zły - tylko najprawdopodobniej (zgaduję) nijak nie ma się do tego co masz zrobić. I w niczym Ci ten "projekt" nie pomoże.

Chyba, że celem aplikacji zakład pogrzebowy - jest ustawModel i dotyczy to ustawiania modelu w trumnie ( na wystawe?)... ciekawe.

Przepraszam, jeśli czujesz się urażony moją arogancją, ale zobacz - zaprojektowałeś aplikację, która równie dobrze może być dla zakładu pogrzebowego, co dla piekarni,
sklepu internetowego, bankomatu, motorówki i serwisu piłki plażowej. Jest to super uniwersalny projekt. Znaczy się "prawdopodobnie" bezużyteczny.

Może dokładnie nie sprecyzowałem, przez co oczywiście przepraszam, ale przedstawiłem jedynie diagram odpowiedzialny za ukazanie "struktury" MVC. Całą logika biznesowa jest schowana w pakietach PracownikPakiet i ObsługaPakiet (także w fazie projektowania). Oczywiście, mogę ją pokazać, ale mi osobiście chodziło o ocenienie samego pomysłu, że do projektu aplikacji, która będzie nam gwarantowała jeden interfejs dla każdego pracownika zakładu, poprzez który dany pracownik będzie mógł sprawdzić swój harmonogram pracy, sprawdzić stan magazynu itp., oraz drugi interfejs przeznaczony do wprowadzenia zamówienia danego klienta przez jakiegos pracownika do obsługi klienta. Przesyłam jeszcze raz trochę zmodyfikowany diagram klas przedstawiający MVC oraz logikę odnośnie obsługi klienta. Jakby co ObsługaModel zawiera "listę" Zleceń (relacja kompozycji). Oczywiście, odnośnie logiki zawartej w pakiecie ObsługaPakiet nie jest to dokończone i może zawierać błędy.

To projekt na zaliczenie? Czy też biznesowy?
Jeśli biznesowy to olej całe to MVC i zrób przede wszystkim projekt interfejsu użytkownika. Po prostu co widzi, jak widzi i co może zrobić.

Z twojego MVC, że aplikacja ma ogólnie dwa widoki, które trochę się zapowiadają hardkorowo jak na ilość elementów w domenie.

Taka podpowiedź - pytanie pomocnicze. Czy naprawdę jednocześnie na ekranie obsługa widzi wszystkie faktury, pogrzeby, klientów, zmarłych etc.?

Na zaliczenie, ale musi być użyty jakiś wzorzec projektowy i wybór padł na MVC. Generalnie nie wszystko będzie implementowane, więc można "poszaleć". Rozumiem jednak, że tak jak ja ująłem MVC z aktywnym modelem, to z projektowego punktu widzenia, jest ok ?

Edit:
Przepraszam, że dopiero teraz, ale nie zauważyłem tej podpowiedzi poniżej obrazkami. Rozumiem, że ta podpowiedź dotyczy relacji jaka dotyczy klasy ObslugaModel oraz klasy Zlecenie ?

Jak na zaliczenie i musi być jakiś wzorzec projektowy - to trzeba było wziąć Singleton: Jest jeden Zakład Pogrzebowy - Singleton - dziękuje.

A to MVC nie jest OK. Najbardziej to widać w ObsługaKontroller operacjach typu: stwórzZlecenie.
Napisz co się wtedy dzieje jak ktoś to wykona - w szczególności co widzi użytkownik (i jak to co widzi wynika z modelu).
W szczególności co się stanie jak 3 razy wybiore stwórzZlecenie.

Podpowiedź utrudniająca: W MVC to co prezentuje Widok wynika z Modelu - w twoim modelu nigdzie nie ma czegoś takiego jak "aktualne zlecenie", "zlecenie niedokończone" itp.
I teraz masz dwa wyjścia: albo idziesz w stronę Apple -> dużo więcej malych widoków i modeli (każde zlecenie ma swój model i widok), albo
bardzo rozbudowujesz swój model - tak, żeby zawierał on więcej kontekstu...(ups!).

I jak to zaczniesz robić to zobaczysz, że ogólnie MVC średnio nadaje się do robienia interfejsów użytkownika - zdziwiony? No cóż - nie chcę wchodzić w ten flame,
po prostu większość developerów i frameworków używa nazwy MVC bez pojęcia co to oznacza.

Odsyłam do http://www.martinfowler.com/eaaDev/uiArchs.html
a w szczególności do fragmentów z ApplicaionModel i MVP (porównanie z MVC)

Jakby co, to miałem wybór między DAO a MVC, więc dużego wyboru nie miałem ;) Ale dzięki za informację odnośnie tego, że MVC średnio się nadaje do interfejsów.
Teraz powiem jak to mniej więcej chce, żeby wyglądało od strony obsługi klienta:
Przede wszystkim pokazuje nam się, czy chcemy stworzyć nowe zlecenie czy aktualizować już złożone, które jest w naszej bazie danych (aktualizować, bo ktoś może doniesie jakieś dokumenty, jednak chce inny wieniec itp. ). Wybieramy opcję nowego zlecenia i pokazują nam się jeden po drugim, czyli najpierw wybór usługi jaką chcemy, następnie wprowadzenie danych klienta, później zmarłego (tutaj można byłoby dołączyć niezbędne dokumenty do zlecenia), dalej uszczegółowienie danego zlecenia, przy czym jak np. klient wybiera trumnę, to wyświetli się na ekranie nam zestaw wzorów, pracownik wybierze wzór, który mu wskaże klient. Po określeniu szczegółów wyjdzie nam opcja dotycząca wygenerowania faktury, a następnie na wygenerowania umowy. Na końcu zostaje wszystko wprowadzone do bazy danych oraz przydzielenie konkretnym pracownikom zadania dotyczące tego zlecenia.

Co do aktualizacji, to po prostu wyświetli się okienko, w którym pracownik wpisze, czy to nazwisko klienta, zmarłego czy identyfikator zlecenia i wtedy pokażą się opcję modyfikacji zlecenia.

Czyli krótko rozumiem, że dla każdego okienka, jak np. do wprowadzania danych klienta mam zrobić osobny widok ? Ze względu na to, że nie musimy do końca zajmować się widokiem na tym etapie projektu, to po prostu olałem to i wszystkie te okienka liczyłem do widoku do obsługi klienta.

I dziękuje za podany link, na pewno zajrzę.

Generalnie tak. To co widzi na ekranie użytkownik to jest jakiś widok, kórego stan ma jakoś wynikać z modelu. Po linii najmniejszego oporu - to po prostu powinieneś zrobić więcej Widoków - i np. do widoku Edycja zlecenia - odpowiada w Modelu obiekt Zlecenie itd....
BTW. nie jestem ekspertem w dziedzinie robienia MVC - zawsze uważałem, że dokładne projekty UI w Photoshopie lub PowerPoincie, Balsamiq są dużo ważniejsze od wszelkich wzorców.

MVC jako takie jest wbrew pozorom trudne w implementacji bo wymaga kombinowania z Obserwatorami żeby Widok automatycznie zmieniał się pod wpływem zmian w Modelu. Dużo wygodniejsze jest MVP bo mamy jasny przepływ sterowania - guziczki itd podpięte pod akcje Prezentera a Prezenter wykonuje operacje na Modelu i decyduje jak renderować Widok. Dodatkowo dzięki temu generalnie można sobie oderwać w ogóle Widok od Modelu, bo renderowanie Widoku będzie odbywać się na podstawie danych wysyłanych z Prezentera i można je sobie dowolnie transformować, a nie kombinować z jakimś odwzorowaniem 1:1 między danymi a kontrolkami.

Okej... Dziękuje Wam bardzo za udzielone rady, które postaram się jakoś wcielić w życie.