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 

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

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 

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.

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.

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...

A dlaczego to nie jest prawdziwe MVC?

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


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

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).

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.

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.

To wiem.

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.

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ą.