Dobra praktyka MVC, Czy widok powinien mieć logikę |
Dobra praktyka MVC, Czy widok powinien mieć logikę |
4.11.2019, 08:00:25
Post
#1
|
|
Grupa: Zarejestrowani Postów: 6 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. 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); |
|
|
4.11.2019, 13:34:12
Post
#2
|
|
Grupa: Zarejestrowani Postów: 6 365 Pomógł: 1114 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. -------------------- |
|
|
4.11.2019, 18:20:25
Post
#3
|
|
Grupa: Zarejestrowani Postów: 6 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 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
wersja b
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 ? |
|
|
4.11.2019, 20:00:34
Post
#4
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 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ć.
|
|
|
4.11.2019, 20:01:10
Post
#5
|
|
Grupa: Zarejestrowani Postów: 6 365 Pomógł: 1114 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. -------------------- |
|
|
4.11.2019, 20:52:07
Post
#6
|
|
Grupa: Zarejestrowani Postów: 2 592 Pomógł: 445 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. -------------------- |
|
|
4.11.2019, 21:25:29
Post
#7
|
|
Grupa: Zarejestrowani Postów: 6 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... 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 |
|
|
5.11.2019, 09:51:31
Post
#8
|
|
Grupa: Zarejestrowani Postów: 2 592 Pomógł: 445 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. -------------------- |
|
|
Wersja Lo-Fi | Aktualny czas: 30.03.2024 - 08:28 |