Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Dobra praktyka MVC
Forum PHP.pl > Forum > PHP
okatse
Witam

Pytanie dotyczy dobrej praktyki w stosowaniu MVC a dokładniej:
a) widok - czy powinien zawierać elementy logiki - np: kontroler przekazuje do widoku dane -> widok sprawdza uprawnienia lub na podstawie uprawnień renderuje część danych (do których user ma uprawniania ) a resztę pomija ? Czy może powinno to wyglądać tak że kontroler przekazuje do widoku tylko te dane do których user ma uprawnienia a widok jakoś musi sobie poradzi z ewentualnym brakiem kompletu danych.

cool.gif w frame-workach php opartych o MVC przyjęło się że widok to zazwyczaj kod html. Czy dobrą praktyką będzie tworzenie widoków także dla metod które nie kończą się wyświetleniem strony ? Na przykład gdy wchodzimy pod jakiś URI to kontroler uruchamia metodę renderującą (zazwyczaj html) ale gdy strzelamy pod URI ajaxem to czy powinien istnieć specjalny widok zwracający json czy wystarczy w kontrolerze echo json_encode($output);
viking
a) Bardzo często tak się robi choćby w blade i laravelu (dyrektywa @can).
b) Tutaj albo odpytanie powinno iść do API, albo większość rozwiązań oferuje metodę typu disableLayout która automatycznie wyłącza renderowanie widoku z plików.
okatse
viking - dzięki za odpowiedź ale :
Cytat
a) Bardzo często tak się robi choćby w blade i laravelu (dyrektywa @can).

tylko które podejście się często robi - bo w pytaniu zawarłem dwa sposoby

Cytat
cool.gif Tutaj albo odpytanie powinno iść do API, albo większość rozwiązań oferuje metodę typu disableLayout która automatycznie wyłącza renderowanie widoku z plików.

metoda z disableLayout jest mi znana jak najbardziej - tylko że to nie rozwiązuje problemu bo wtedy nadal mamy metodę kontrolera która kończy swoje działanie wywaleniem rezultatu bezpośrednio jako output - czyli brak zdefiniowanego widoku. Po prostu metoda się kończy a jej wynik zwracany jest do domyślnego outputa. I tu moje pytanie czy w dobrym tonie jest aby jednak nie pozostawiać tego tak sobie luzem i trochę sztucznie i na siłę stworzyć jednak widok - może przykład
wersja a
  1. class Test {
  2.  
  3. public function get_dane()
  4. {
  5. $imie = 'Jan';
  6. echo $imie;
  7. }
  8.  
  9. }


wersja b

  1. class Test {
  2.  
  3. public function get_dane()
  4. {
  5. $imie = 'Jan';
  6. $this->render('plik_widoku', $imie);
  7. }
  8.  
  9. }
  10.  
  11. plik widoku
  12.  
  13. if( isset($imie))
  14. echo $imie;


W obu przypadkach metodę get_dane wywołuje po przez ajax. W wersji A wynik działania jest po prostu rysowany na output a w wersji B użyty jest widok - trochę sztucznie i na wyrost ale w końcu jest to oparte o wzorzec MVC więc może powinno być tak robione nawet jeśli jest na wyrost ?
Pyton_000
Zwróć to co ma dostać Ajax i olej. Jeśli oczekujesz HTML to wywal HTML, jeśli JSON to JSON. Nie ma sensu na siłę sztucznie kombinować.
viking
Raczej nie powinieneś przekazywać danych do których użytkownik nie ma uprawnień. Jeśli jakimś sposobem się wyświetlą to co wtedy? Zawsze można podzielić szablony na mniejsze fragmenty i w nich sprawdzać dane uprawnienia.

A kto powiedział że ma być jeden kontroler? Może być jakiś ogólny oraz np JsonController. W przypadku ajaxa odpowiedź może być dowolnego typu json, html, xml dlatego nie ma jednoznacznej odpowiedzi co konkretnie stosować. Możesz mieć jakiś system szablonów który świetnie radzi sobie z XML i czemu miałbyś rezygnować z niego, ale może to być prosta odpowiedź gdzie nawet sam kontroler wygeneruje te kilka linijek kodu.
vokiel
a. Bezpieczniej gdy kontroler generuje tylko te dane, które są potrzebne. Czyli np jeśli wykryje że użytkownik nie powinien czegoś zobaczyć, to tych danych nie przekazuje do widoku. Lub opcja druga - wybiera inny widok, który tych danych nie renderuje w ogóle.

b. Żeby nie powielać kodu to jeden kontroler będzie ok, wystarczy w nim sprawdzenie typu isAjax() i zwrócenie samych danych, a w przypadku zwykłego requesta renderowanie widoku.
okatse
Ok dzięki za odpowiedzi.
To mam jeszcze inne pytanie. Gdzie się powinno sprawdzać (czy w modelu , kontrolerze czy widoku) uprawnienia przy zapisie i odczycie? Czy te schematy poniżej są poprawne ?
Zapis
Z formularza dane trafiają do kontrolera , kontroler wczytuje model -> model waliduje dane i sprawdza uprawnienia czy zalogowany user może zapisać te pola do bazy i zapisuje tylko te do których user ma prawo

Odczyt
a) Kontroler wczytuje model -> model odczytuje dane z bazy (wszystkie pola, po prostu wykonuje zapytanie bez sprawdzenia uprawnień)-> kontroler przekazuje dane do widoku -> widok sprawdza uprawnienia i renderuje tylko te pola do których zalogowany user ma prawo np IF (access ($pole_x) ) echo 'input...
cool.gif Kontroler wczytuje model -> model (sprawdza uprawnienia) odczytuje tylko pola do których user ma prawo -> w widoku jest seria IF sprawdzająca IF(isset( $pole_x) ) echo 'input...
c) inne rozwiązanie
vokiel
Jako, że w aplikacjach webowych bliżej jest do MVP niż do MVC ja jestem za tym, żeby to kontroler kontrolował dostępy, rozporządzał danymi, był punktem styku pomiędzy danymi a ich prezentacją.

Tym samym:
Zapis - dane z formularza trafiają do kontrolera, ten sprawdza czy użytkownik na wystarczające uprawnienia do zapisania tych danych i jeśli tak to wczytuje model i zapisuje dane.
Odczyt - kontroler sprawdza uprawnienia użytkownika, wczytuje model (czasem sprawdza uprawnienia po wczytaniu modelu i pobraniu danych) jeśli użytkownik ma do nich prawo, albo do części z nich to tworzy odpowiednie zmienne, które przekazuje do widoku do wyrenderowania. Kwestia ifów w widoku jest moim zdaniem zależna od projektu, czasem nie warto duplikować widoków tylko po to, żeby wyświetlać w nich wszystko co przekaże kontroler. Lepiej mieć kilka ifów i re-używać widok w kilku miejscach. Czasem lepiej i wygodniej mieć 1:1 - wszystkie dane przekazane do widoku są wyświetlane, jeśli mamy inny poziom uprawnień, inne dane do wyświetlenia - stosujemy inny widok. W czasach twiga i fajnie rozbudowanego dziedziczenia / bloków / makr - można to fajnie zorganizować bez zbędnego duplikowania kodu.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.