Mam takie pytanie - w MVC, model jest generyczny, moze byc uzywany w wielu aplikacjach; widoki sa generyczne, ale juz np. cale formatki / strony chyba niespecjalnie, najczesciej nie da sie przeniesc do innych aplikacji; a jak to jest z kontrolerrami?
Pytanie takie przyszlo mi na mysl po rozmowie z kolega z projektu, ktory robil rozne czary mary zeby kontrolery (w Cocoa Touch na iOS) byly 'uzywalne' w innej aplikacji, i jak by tu powiedziec - okazalo sie to bardzo trudne, napisal mnostwo niepotrzebnego kodu, pelno abstrakcji, a i tak nie da sie tego kontrolera uzyc gdzie indziej. Mi sie z kolei wydaje ze kontroler to jest taki 'glue code' ktory jest specyficzny dla aplikacji i raczej nie da sie go uzyc ponownie. (Pomijam kontrolery typu navigation controller czy tab controller ktore sa tylko kontenerami na inne kontrolery.)
Jakie jest wasze zdanie?
Kontroler trzyma logikę biznesową więc nie do końca może być generyczny. Jednak jest duża grupa zadań, które można zgeneralizować i stworzyć dla nich kontrolery niezależne od aplikacji. Przykładowo proces logowania, rejestracji, przypominania hasła. Jest co do zasady taki sam w wielu aplikacjach i kontroler za to odpowiedzialny można przenieść do jakiejś biblioteki. Kolejna sprawa to np. typowe operacje - wybieranie danych z bazy na podstawie filtra i wysyłanie ich do widoku.
Zatem podsumowując tak da się wydzielić pewien zbiór kontrolerów, które będą niezależne od konkretnej aplikacji.
Koziołek napisał(a):
Kontroler trzyma logikę biznesową
Nie... nie trzyma.
Jeżeli tworzysz jakiś większy system to broń boże żebyś mieszał kod do obsługi GUI (przygotowanie danych dla view, obsługa interakcji) z kodem do obsługi logiki biznesowej (obliczenie stanu magazynowego, przelew kasy między kontami).
MVC to wzorzec do tworzenia GUI, a nie całego systemu. Logika biznesowa jest elementem tzw. domain model i o ten model chodzi w MVC, nie tylko model danych.
V - jest odpowiedzialny za wygląd aplikacji
C - jest odpowiedzialny za interakcje: obsługa klików, przejście do innego widoku/kontrolera, itp.
M - sama konstrukcja modelu domenowego nie jest natomiast definiowana przez wzorzec MVC - jedynie interakcja z nim
W Javie model domenowy jest zazwyczaj modelowany w formie klas usługowych.
Odsyłam do pierwotnego dokumentu co ten wzorzec powołał do istnienia:
http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
Mimo wieku powyższego polecam bo wielu dev'ów nigdy nie pofatygowało się żeby przeczytać jakiś sensowny dokument na temat tego wzorca, a swoją wiedzę bazują na blogach i "zajebistych" frameworkach webowych, które dosłownie dokonują gwałtu na MVC.
PS. De facto w typowych aplikacjach dominuje wzorzec MVP, MVVM.
Co do pytania autora. Pisanie na siłę generycznego kodu nigdy nie ma sensu. MVC jest stosowany głównie żeby uzyskać dobre "separation of concerns", a nie generyczny.
Są sytuacje gdzie MVC natomiast może pomóc z generycznością, przykłady:
- dane z giełdy - może je przedstawić na dwóch widokach (tabelkowy lub wykres), a interakcje z nimi w jednym kontrolerze,
- uniwersalna tabelka - masz generyczny view co potrafi wyświetlić kolekcję różnych obiektów (ich własności wyciąga na zasadzie refkelsji obiektowej), do którego podpinasz zawsze specyficzny kontroler aby do odpowiedniego miejsca w modelu domenowym przekierował operacje CRUDowe
Ale take generyczne komponenty nie robi się dla sztuki, a tylko wtedy gdy są nam potrzebne - bo kosztują więcej roboty.