[MVC] Widok nie odwołujący się bezpośrednio do modelu? Opcje

[MacDada]

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

[Zyx]

Jakie setki ifów? Słyszał waść o wyjątkach? (IMG:style_emoticons/default/smile.gif) Rzecz jest prosta: widok nie łapie wyjątków modelu, dzięki czemu może odebrać je kontroler i zareagować, kierując do standardowego systemu obsługi błędów modelu.

Jeśli chodzi o kwestię różnych typów widoków, umiejscowienie komunikacji niewiele zmienia. Podam Ci przykład w pseudokodzie:

[PHP] pobierz, plaintext 
public function someAction()
{
   switch($request->view)
   {
      case 'html':
          $view = new View_Something_Html;
          break;
      case 'xml':
          $view = new View_Something_Xml;
          break;
      case 'json':
          $view = new View_Something_Json;
          break;
   }
   $view->addModel('datasource', new Some_Model);
   return $view;
} // end someAction();
[PHP] pobierz, plaintext 

Pamiętaj, że widok to nie tylko kod HTML (szablony), ale też logika prezentacji. Stronicowanie wyników ma sens w przypadku HTML-a, ale może nie mieć w formacie JSON lub PDF. Obsługa stronicowania to zadanie widoku - dzięki powyższemu podejściu, gdzie widok sam sobie pobiera dane, kontroler nie musi nawet wiedzieć, co dokładnie jest mu potrzebne do wykonania swojego zadania. Jeśli widok nie komunikuje się z modelem, kod ten musi wylądować w kontrolerze i wtedy nagle tu się pojawia mnóstwo ifów, a kod kontrolera staje się długi i przeładowany.

Ponadto warto zwrócić uwagę, że da się stworzyć tzw. uniwersalne widoki wielokrotnego przeznaczenia. Jest to coś, co ciężko uświadczyć we frameworkach, które warstwę widoku zredukowały do systemu szablonów. Mam sobie uniwersalny widok do wyświetlania listy elementów, który ma już wbudowaną obsługę stronicowania, sortowania, filtrowania i co tam sobie jeszcze wymarzysz. Jeśli wszystkie dane idą przez kontroler, a ja będę chciał gdzieś sobie zrobić listę elementów, muszę zrobić Ctrl+C i Ctrl+V całego kodu, a następnie go popoprawiać, lub też obudować sztuczną atrapą, która sprowadzi nas do MVC. Tymczasem ja sobie robię:

[PHP] pobierz, plaintext 
public function displayMeSomethingAction()
{
    $model = new Model_Something;
    $model->id = $request->getParam('id', null);
    $view = new View_List;
    $view->controllerIdentity = $this->getControllerIdentity(); // Dzięki temu widok może prawidłowo ustawić np. breadcrumbs i tytuł
    $view->addModel('list', $model);
 
    return $view;
} // end displayMeSomethingAction();
[PHP] pobierz, plaintext 

I co? 6 linijek, a ja mam listę elementów modelu z sortowaniem, stronicowaniem, filtrowaniem i wszystkim, co sobie tylko model zażyczy. Jeśli tę samą sztuczkę chcę powtórzyć w innym miejscu, mogę to od razu zrobić, bo jedyne, co tak naprawdę muszę zrobić, to wprowadzić model do gotowego widoku. Kod kontrolera jest krótki i przejrzysty, dzięki czemu po dodaniu uwierzytelniania i kontroli uprawnień wciąż nadaje się do czytania.

PS. Jeśli chcesz poeksperymentować z tego typu rzeczami, to obejrzyj sobie mój eksperymentalny framework stworzony do tego celu: http://github.com/zyxist/Trinity . Kod jest publicznie dostępny i możesz namacalnie sprawdzić, jak to działa w praktyce.

Ten post edytował Zyx 27.07.2010, 21:29:09