![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 47 Pomógł: 1 Dołączył: 24.06.2010 Skąd: Sopot Ostrzeżenie: (0%) ![]() ![]() |
Hej,
przeczytałem kupę tematów o MVC na forum i zastanawia mnie tu jedna rzecz. Większość osób pokazuje schemat działania aplikacji jako taki: 1.) Kontroler rozpoznaje co użytkownik chce zrobić (np wyświetlić listę użytkowników). 2.) Kontroler odpala wtedy odpowiedni widok. 3.) Widok odpala model. 4.) Model przerabia co tam potrzebuje i zwraca dane do widoku. 5.) Widok prezentuje dane. Co mnie dziwi to fakt, że w ten sposób jeśli zmienię model, to muszę ingerować też w pliki widoku. Jest on uzależniony od konkretnego modelu. No i widok bezpośrednio współpracuje z modelem, a kontroler pełni funkcję jedynie routera. Czy w takim razie nie lepszy byłby schemat taki? 1.) Kontroler rozpoznaje co użytkownik chce zrobić (np wyświetlić listę użytkowników). 2.) Kontroler wybiera model i go odpala. 3.) Model przerabia co tam potrzebuje i zwraca dane do kontrolera. 4.) Kontroler wybiera widok i przekazuje mu dane od modelu. 5.) Widok wyświetla dane. W ten sposób Kontroler rzeczywiście pełni funkcję pośredniczącą między warstwą danych i działań, a warstwą prezentacyjną. Mogę stworzyć różne widoki do reprezentowania tego samego typu danych, a jednocześnie mogę mieć wiele źródeł danych, które będą wyświetlane przez ten sam widok. Co więcej upraszcza to schemat akcji, który może wyglądać tak: 1.) Kontroler rozpoznaje, co użytkownik chce zrobić (np dodać nowego użytkownika do bazy). 2.) Kontroler wybiera model i go odpala. 3.) Model przerabia co tam potrzebuje i zwraca dane do kontrolera (np kod błędu, kod sukcesu, itd.) 4.) Kontroler wybiera widok i przekazuje mu dane od modelu. 5.) Widok wyświetla dane. Voila! Okazuje się w ten sposób, że model jest równoważny akcji. Model służy wszystkim operacjom na danych, kontroler służy rozpoznawaniu tego co chce użytkownik i tego co chce model, a widok służy do prezentowania danych przekazanych mu przez kontroler. Co więcej, jeśli widok zwróci błąd, to kontroler znów rozpoznaje co się dzieje i odpala odpowiedni model jako reakcję, np logger. Pure MVC? Czy może jednak w takim podejściu tkwi jakiś błąd? pozdr. Ten post edytował MacDada 27.07.2010, 18:50:34 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 47 Pomógł: 1 Dołączył: 24.06.2010 Skąd: Sopot Ostrzeżenie: (0%) ![]() ![]() |
OK, czyli mechanizm, który opisałem to MVP. Próbowałem przeanalizować kod z git-huba z „prawdziwym MVC”, ale po kilku plikach doszedłem do wniosku, że nie potrzebuję w swoich projektach aż takiej komplikacji. MVP w zupełności mi na razie odpowiada (IMG:style_emoticons/default/smile.gif)
W każdym razie dzięki Zyx, bo widzę, że nie pierwszy raz się produkowałeś na ten temat... (IMG:style_emoticons/default/winksmiley.jpg) http://www.zyxist.com/en/archives/16 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 3.10.2025 - 10:10 |