[PHP]MVC - co przekazywać widokowi, a czego nie? Opcje

[SmokAnalog]

Witajcie,

dzisiaj mam taką małą zagwostkę na temat wzorca Model View Controller. Czy powinno się przekazywać widokom instancje generowane przez modele? Innymi słowy, czy nazwa klasy ma w ogóle prawo znaleźć się w widoku?

Przykład: mamy metodę, która pobiera obiekt zalogowanego użytkownika, a w widoku wypisujemy jego login. I teraz mamy dwie możliwości:

1. Użyć klasy w modelu, np.:
   
   W widoku:
   

   [PHP] pobierz, plaintext 
   Witaj, <?php echo User::getLoggedIn()->login ?>!
   [PHP] pobierz, plaintext 

2. Przekazać obiekt użytkownika widokowi, np.:
   
   W kontrolerze:
   

   [PHP] pobierz, plaintext 
   $view->user = User::getLoggedIn()
   [PHP] pobierz, plaintext 

   
   
   W widoku:
   

   [PHP] pobierz, plaintext 
   Witaj, <?php echo $this->user->login ?>!
   [PHP] pobierz, plaintext 

[Spawnm]

Oba przykłady są stosowane przez programistów, osobiście zalecał bym nr. 2.

[markonix]

Osobiście obiekt zalogowanego użytkownika tworze gdzieś wyżej (w core kontrolerze) i w zależności od klasy widoku tam już go przekazuje do widoku albo dołączam do tablicy zmiennych, które pójdą do widoku. Po prostu obiekt zalogowanego użytkownika przydaje się w wielu miejscach i kontekstach (zarówno w kontrolerze, zwykle id zalogowanego leci do metod modeli), a w widoku wiadomo jego podstawowe dane, id czy typ konta jeżeli jest takowe.

Powyższe podchodzi bardziej pod punkt 2.

[PHP] pobierz, plaintext 
<?php
// kontroler główny, np. w CI w core Controller
$this['data']['logged'] = User::getLoggedUser();
 
// widok
<?= $logged->username ?>
[PHP] pobierz, plaintext 

Ten post edytował markonix 19.10.2013, 21:03:22

[SmokAnalog]

Markonix, to co piszesz ma dużo sensu. Korzystam z własnego mini-framerowka MVC. Cały core jest przetwarzany w index.php. Zdaję sobie sprawę, że pobieranie zalogowanego użytkownika w klasie nie jest idealnym rozwiązaniem. Ewentualnie można by stworzyć osobną klasę, np. Authentication, która byłaby klasą statyczną. Ciekawy problem, w sumie oba rozwiązania mają sens, ale dla zachowania "dziewiczości" klas można by było przekazywać pewne parametry kontrolerom w index.php, najlepiej tak jak zasugerowałeś - w jednym obiekcie, żeby znacząco zmniejszyć prawdopodobieństwo kolizji nazw.

[markonix]

Pewnie ma to jakieś wady związane np. z hermetyzacją bo jest to praktycznie zmienna globalna i każdy kontroler może ją nadpisać (co też z drugiej strony ma zalety bo zawsze ten obiekt można zaktualizować np. w czasie zmiany typu konta, do widoku pójdzie już aktualny typ konta.

[irmidjusz]

W klasycznym MVC widok sam pobiera z modeli to, co potrzebuje do wyświetlenia.
Osobnym zagadnienie jest, że to co mamy na stronach www to nie jest prawdziwe MVC...

[SmokAnalog]

Osobnym zagadnienie jest, że to co mamy na stronach www to nie jest prawdziwe MVC...

A dlaczego to nie jest prawdziwe MVC?

[Spawnm]

Bo jest grupa ludzi która lubi tak gadać. Zaraz pewnie usłyszymy coś równie zabawnego np. że to jest mvp

W klasycznym MVC widok sam pobiera z modeli to, co potrzebuje do wyświetlenia.

Tak, tylko że jest też sprawa gdzie te modele tworzyć. A za dobór modeli odpowiada kontroler.
Tutaj też widok pobiera dane z modeli, jednak pewne modele powinny być dostarczane przez kontroler.
Tak działa mvc

[SmokAnalog]

No właśnie.

Ja wybrałem najprostszą drogę jeśli chodzi o tworzenie modeli, czyli __autoload. Stąd moja wątpliwość, bo u mnie modele są ładowane w widoku.

Po drugie, widok ma dostęp do wszystkich metod modelu, czyli może bezpośrednio operować na danych (jeśli model ma np. metody zapisujące do/usuwające z bazy).

[Spawnm]

Widok nie powinien wykonywać modyfikacji na bazie, jego zadaniem jest jedynie prezentacja danych.
Modyfikacje wykonuje model wywołany w kontrolerze.
Autoload to nie tworzenie modeli, tylko wczytywanie plików z klasami.

[skowron-line]

Idąc ścieżką MVC musisz do widoku przekazać obiekt klasy Modelu.

[PHP] pobierz, plaintext 
public function action_index()
{
	View::factory('nazwa_widoku')
		->set('user', new Model_User());
}
[PHP] pobierz, plaintext 

A w widoku odwołujesz się do metod Modelu.
Inną sprawą jest to jakie rozwiązania proponują twórcy FW.

[SmokAnalog]

Widok nie powinien wykonywać modyfikacji na bazie, jego zadaniem jest jedynie prezentacja danych.

To wiem.

Modyfikacje wykonuje model wywołany w kontrolerze.

To też wiem, ale czy zabezpiecza się jakoś te metody? Czyli np. fabryka modeli ustala kontekst dla danego modelu, blokując tym samym pewne metody (albo lepiej, w kontekście kontrolera odblokowując pewne metody)? Wyobrażam sobie to mniej więcej tak:

[PHP] pobierz, plaintext 
$user = Model::factory('User', array('id' => 5), Model::READ);
[PHP] pobierz, plaintext 

oraz

[PHP] pobierz, plaintext 
$user = Model::factory('User', array('id' => 5), Model::READ_WRITE);
[PHP] pobierz, plaintext 

Ta druga przekazałaby do obiektu klasu User jakąś zmienną, np.

[PHP] pobierz, plaintext 
$result->_write = true;
[PHP] pobierz, plaintext 

A wszystkie metody zapisujące sprawdzałyby:

[PHP] pobierz, plaintext 
if($this->_write) {...}
[PHP] pobierz, plaintext 

Dobrze kombinuję?

Można też pomyśleć o tworzeniu osobnych klas, np. User i User_Write (extends User), a fabryka dobierałaby nazwę klasy na podstawie parametru kontekstu.

[Spawnm]

A nie lepiej po prostu myśleć co się robi? Widok w mvc nie modyfikuje i tyle w temacie

[SmokAnalog]

A nie lepiej po prostu myśleć co się robi? Widok w mvc nie modyfikuje i tyle w temacie

Nie, nie lepiej. Gdyby tak było, to by w ogóle nie wymyślano programowania obiektowego. Model MVC powstał m.in. po to, żeby pozwolić front-endowcom i back-endowcom pracować równolegle na żywych danych. Oczywiście, możesz powiedzieć frontowi: "ej, tych metod nie używaj", ale to nieszczególnie rozsądne.

Trochę mnie rozbawiłeś tą odpowiedzią.