Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Dobra praktyka MVC, Czy widok powinien mieć logikę
okatse
post 4.11.2019, 08:00:25
Post #1





Grupa: Zarejestrowani
Postów: 4
Pomógł: 0
Dołączył: 4.11.2019

Ostrzeżenie: (0%)
-----


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);
Go to the top of the page
+Quote Post
viking
post 4.11.2019, 13:34:12
Post #2





Grupa: Zarejestrowani
Postów: 5 430
Pomógł: 925
Dołączył: 30.08.2006

Ostrzeżenie: (0%)
-----


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.


--------------------
Go to the top of the page
+Quote Post
okatse
post 4.11.2019, 18:20:25
Post #3





Grupa: Zarejestrowani
Postów: 4
Pomógł: 0
Dołączył: 4.11.2019

Ostrzeżenie: (0%)
-----


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 ?
Go to the top of the page
+Quote Post
Pyton_000
post 4.11.2019, 20:00:34
Post #4





Grupa: Zarejestrowani
Postów: 7 821
Pomógł: 1375
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


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ć.
Go to the top of the page
+Quote Post
viking
post 4.11.2019, 20:01:10
Post #5





Grupa: Zarejestrowani
Postów: 5 430
Pomógł: 925
Dołączył: 30.08.2006

Ostrzeżenie: (0%)
-----


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.


--------------------
Go to the top of the page
+Quote Post
vokiel
post 4.11.2019, 20:52:07
Post #6





Grupa: Zarejestrowani
Postów: 2 449
Pomógł: 414
Dołączył: 12.03.2007

Ostrzeżenie: (0%)
-----


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.


--------------------
Go to the top of the page
+Quote Post
okatse
post 4.11.2019, 21:25:29
Post #7





Grupa: Zarejestrowani
Postów: 4
Pomógł: 0
Dołączył: 4.11.2019

Ostrzeżenie: (0%)
-----


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
Go to the top of the page
+Quote Post
vokiel
post 5.11.2019, 09:51:31
Post #8





Grupa: Zarejestrowani
Postów: 2 449
Pomógł: 414
Dołączył: 12.03.2007

Ostrzeżenie: (0%)
-----


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.


--------------------
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 15.12.2019 - 01:53