MVC - różnice w opisie oraz MVP i MVVM

Question

Hejka, mam pytanie odnośnie prawidłowego opisu graficznego modelu MVC. Patrząc na grafiki w necie widzę dużą rozbieżność w samej idei. Np. w niektórych przypadkach Widok jest połączony z model, w innych nie. Znalazłem też taką grafikę i po zastanowieniu wydaje mi się, że najtrafniej pokazuje schemat działania MVC, ale może się mylę?

I teraz nasuwa mi się pytanie, jak wyglądać powinny opisy graficzne modeli MVP i MVVM by naprawdę odpowiadały realnemu flow, który odbywa się podczas pracy aplikacji? Będę wdzięczny za linki, Oczywiście jest masa porównać w necie, ale cały czas nie może mi to do końca zaskoczyć

Answer 1

Jakby być bardzo dokładnymi, to to bardziej pasuje do wzorca MVP, bo to właśnie tam Presenter jest odpowiedzialny za komunikację z modelem i odświeżanie widoku. W takim czystym MVC model wpływa bezpośrednio na widok. Wikipedia (angielska) ma w sumie całkiem spoko diagramy.

Chociaż IMO to nie jest szczególnie istotne, bo wzorce MV* są tak często mieszane, że właśnie często się mówi o MV* niż o jakimś konkretnym wzorcu.

Comments

To rozważania trochę akademickie, ale chcę dobrze zrozumieć ideę. Wtedy gdy będę analizował kod, to będzie mi łatwiej wychwycić co kto mieszał i z czym

W takim czystym MVC model wpływa bezpośrednio na widok.

No właśnie teraz robię projekt w PHP i Laravelu i korzystam z dokumentacji i właśnie to nie tak jest realizowane. To kontroler pobiera dane z modelu, wysyła dane do widoku i widok po przetworzeniu zwraca dane do kontrolera i ten je wysyła do przeglądarki. Jest to idealnie i precyzyjnie rozdzielone. Dlatego bardzo mnie dziwią te diagramy gdzie np. widok ma połączenie z modelem.

 

---

No właśnie teraz robię projekt w PHP i Laravelu i korzystam z dokumentacji i właśnie to nie tak jest realizowane.

A skąd założenie, że Laravel to MVC? 

Dla mnie to serio nie ma znaczenia, czy framework jest MVC, czy MVP – bez różnicy. Te wzorce praktycznie zatraciły swoje pierwotne znaczenie i często są tak mieszane, że nie sposób odróżnić jeden od drugiego. Tak naprawdę o wiele ważniejsze jest sensowne podzielenie aplikacji na poszczególne moduły ze względu na odpowiedzialności poszczególnych części kodu (SRP). Zaryzykowałbym wręcz stwierdzenie, że w typowym MVC ten podział jest mocno rozwodniony, bo tak naprawdę istnieją trzy warstwy. W obecnych frameworkach tych warstw jest zdecydowanie więcej i architektura idzie raczej w stronę cebuli.

---

Sam Laravel to faktycznie można użyć bez MVC, ale w dokumentacji jest też pokazane jak użyć go z tym wzorcem i odnoszę się tylko do tej części

---

Hm, prawdę mówiąc nie widzę takiej sekcji w dokumentacji. Mógłbyś podesłać linka?

---

W obecnych frameworkach tych warstw jest zdecydowanie więcej i architektura idzie raczej w stronę cebuli.

Masz rację, muszę wrócić do Uncle Bob

---

Hm, prawdę mówiąc nie widzę takiej sekcji w dokumentacji. Mógłbyś podesłać linka?

1. Routing do kontrolera https://laravel.com/docs/9.x/routing#the-default-route-files
2. Controller zwraca już przetworzony View https://laravel.com/docs/9.x/controllers#basic-controllers
3. No i tu konfiguracja Model https://laravel.com/docs/9.x/eloquent#eloquent-model-conventions

---

Hm, tbh nie traktowałbym tego jako poradnik MVC. Kontroler w tym wydaniu to raczej po prostu określenie fragmentu kodu, który odpowiada na żądanie HTTP użytkownika (na co wskazuje zresztą sam namespace bazowej klasy kontrolera). No i to, że zwraca statyczny view, to też można argumentować, że to nie MVC, bo w MVC view nie jest statyczny i nie powinien być zwracany przez kontroler.

Eloquent też nie jest takim typowym modelem z MVC, bo on de facto jest warstwą abstrakcji na bazę danych. A model w MVC raczej powinien być poziom wyżej (ukrywać przed aplikacją, skąd pochodzą surowe dane).

To nie jest "czyste" MVC i zauważ też, że nigdzie w dokumentacji Laravela nie pada ten termin (ani nawet MV*).

---

Prawdą jest, że gdy widok jest konstruowany dynamicznie zazwyczaj przekazuje się mu odpowiednie modele na których podstawie ma wygenerować stronę. Nie muszą być to zawsze te same modele które są w bazie danych. Być może chcielibyśmy w kontrolerze wstępnie dane przetworzyć i podać widokowi od razu spreparowane pod niego obiekty.

---

Nie powiedziałbym, że w bazie danych wgl są jakieś modele. W bazie danych są po prostu dane. Model z kolei jest po stronie kodu i w jakiś sposób reprezentuje te dane. W MV* jest też często tym miejscem, w którym znajduje się jakaś walidacja itd. (bo to w sumie jedyna z trzech warstw, gdzie ta walidacja pasuje).

Answer 2

MVC - Controller jest naszym głównym elementem, trzyma w sobie/tworzy modele oraz widoki i je kontroluje 

MVP - Wzorzec często wykorzystywany w Windows Forms. Tutaj widok jest naszym rootem i to on trzyma w sobie Presentera i wywołuje z niego odpowiednie metody w odpowiednich eventach. Prezenter natomiast ma w sobie modele.

MVVM - Wzorzec wykorzystywany w WPF. Tutaj wykorzystuje się tzw. binding. WIdok na bieżąco aktualizuje swój stan do View Modelu. View Model trzyma reprezentację widoku, zmiana jakiejś wartości w nim skutkuje zmianą widoku. VM trzyma w sobie także Model i wszystko kontroluje.

Ogólnie celem tych wszystkich rozwiązań jest większa modułowość. Odseparowanie od siebie modeli, widoków i kontrolerów. Np. można mieć ten sam ViewModel dla kilku różnych widoków. 

Comments

Co do schematu to DB raczej powinno mieć strzałki z Controllerem, choć z Modelem też jakiś sens ma. Btw. czy DB i Model na schemacie to nie to samo?

No i dlaczego są strzałki w obie strony między Controllerem a Widokiem? Wydaje mi się, że albo Jest strzałka z kontrolera do widoku i z widoku do przeglądarki, albo z widoku do kontrolera i z kontrolera do przeglądarki.

---

Co do schematu to DB raczej powinno mieć strzałki z Controllerem, choć z Modelem też jakiś sens ma. Btw. czy DB i Model na schemacie to nie to samo?

IMO jest ok. Kontroler nie powinien wiedzieć nic o bazie danych, bo ta jest szczegółem implementacyjnym, która jest przykrywa przez model.

---

Też tak mi się wydaje, że model jest pośrednikiem pomiędzy kontrolerem i bazą danych. W Laravelu w kontrolerze buduję za pomocą Eloquent odpowiedni obiekty, który wysyłam do modelu, a ten tłumaczy go na SQL wysyła do bazy, potem otrzymuje odpowiedź, zamienia ją na obiekt i zwraca do kontrolera, gdzie ten obiekty przekazuję do widoku, widok generuje stronę i kontroler wysyła ją do przeglądarki.

---

Tak, ta ogólna idea jak rozróżnić poszczególne model jest mi znana, ale jak zwykle diabeł tkwi w szczegółach i o te szczegóły biega No co ja poradzę, że lubię takie rzeczy mieć rozkminione i zrozumiane, dlatego dziurę wiercę dalej Czy znasz jakieś artykuły, które trochę głębiej poruszają ten temat? Wikipedia oczywiście przeczytana i różne artykuły też, ale to ciut jeszcze ogólnikowo, jakiś przykładów mi trzeba najlepiej w wersji graficznej

---

Grafika nie jest sama w sobie poprawna niestety, tutaj strzałki nie są - strzałkami typowo wskazującymi na zależność czy relacje, wiem to z autopsji gdyż pamiętam komentarze i dyskusje na linked-in a sam autor, potwierdził, że jest to tylko schemat pokazujący "jakąś relacje", nie konkretną.
Dużo lepiej skorzystać z 

---

No właśnie tu mam zgrzyt, bo to co user wybierze najpierw jest interpretowane przez router i dopiero na tej podstawie odpalany jest odpowiedni kontroler i funkcja.... a biorąc pod uwagę taki kod kontrolera...

<?php

    namespace App\Http\Controllers;

    use App\Models\Doctor;
    use Illuminate\Http\Request;
    use Illuminate\View\View;

    class DoctorsController extends Controller
    {
        public function index(): View
        {
            $doctors = (new Doctor)->where('is_active', '=', true)->get();

            return view("doctors.index", ['doctors' => $doctors]);
        }

        public function search(Request $request): View
        {
            // Get the search value from the request
            $search = $request->input('search');

            // Search in the title and body columns from the posts table
            $doctors = Doctor::query()
                ->where('name', 'LIKE', "%{$search}%")
                ->orWhere('surname', 'LIKE', "%{$search}%")
                ->orWhere('specialization', 'LIKE', "%{$search}%")
                ->get();

            // Return the search view with the results compacted
            return view('doctors.search', compact('doctors'));
        }
    }

I taki view

@extends('main')

@section('menu')
    @include('doctors.menu')
@endsection

@section('style')
    <link type="text/css" rel="stylesheet" href="/css/materialize.css" media="screen,projection"/>
@endsection

@section('content')
    <div class="container">
        <div class="row">
            <div class="col s12 m6 l6">
                <a href="/doctors/">
                    <div class="card-panel hoverable center">
                        <h5>All doctors</h5>
                    </div>
                </a>
            </div>
            <div class="col s12 m6 l6">
                <a href="/doctors/search/">
                    <div class="card-panel hoverable center">
                        <h5>Search doctor</h5>
                    </div>
                </a>
            </div>
        </div>
    </div>
@endsection

(nie wrzucałem już szablonu main.blade.php, bo to w sumie nie jest tu istotne)
To właśnie nie pasuje mi ta relacja od View do User. Bo tak naprawdę Kontroler zwraca do usera to co otrzyma z Widoku, Widok sam do Usera nic nie wysyła. I ten kod nie jest moim wymysłem, tylko jest stworzony na podstawie dokumentacji Laravel.

---

To, co opisujesz (kontroler decyduje o wszystkim), bardziej pasuje do wzorca MVP. I to jest dokładnie to, o czym mówię: te wzorce są tak wymieszane, że rozróżnianie ich IMO jest bezcelowe. Na froncie od dawna funkcjonuje zbiorcze określenie MV*.

---

Czyli co kucharz to inaczej doprawia tę samą pomidorówkę

Answer 3

Dzięki @Comandeer, @jankustosz1 i @Wiciorny sporo mi się wyjaśniło, widzę że sporo jeszcze nauki i kodowania przede mną. Zatem gdyby szukać nowoczesnych wzorców to rozumiem, że od DDD warto poczytać, czy coś jeszcze?