wtorek, 8 grudnia 2015

Jeśli trafiłeś gdzieś w środek serii, lepiej będzie jak odpalisz te posty w takiej kolejności:
  • Passive MVC vs MVP Passive View (wkrótce...) 
  • Active MVC vs MVP Passive View (wkrótce...) 
  • Passive MVC vs MVP Supervising Controller (wkrótce...) 
  • MVP Passive View i MVP Supervising Controllet (wkrótce...)
To czy dany kawałek kodu można nazwać wzorcem, nie jest wyznacznikiem czy nasz kod jest dobry czy zły. Możemy w ogóle nie pisać używając wzorców lub używać je nieświadomie. Najważniejsze aby osiągnąć pożądany cel.

... ale ...

... zdefiniowanie wzorców i świadome posługiwanie się nimi, oraz używanie odpowiedniego słownictwa może znacznie podnieść zrozumienie kodu oraz poprawić komunikację. Często też wzorce dają nam gotowe rozwiązanie powtarzalnych zagadnień, co sprawia, że nie musimy wymyślać koła na nowo. Znajomość wzorców i ich świadome stosowanie lub świadome pomijanie znacznie zwiększa prawdopodobieństwo na wytworzenie produktu wysokiej jakości. 

Po tym krótkim, lekko filozoficznym wstępie czuje się usprawiedliwiony aby w dalszej części artykułu rozłożyć na czynniki pierwsze wzorzec MVP, porównam go do Passive i Active MVC.

Przekopałem znaczną część internetu oraz zajrzałem do dwóch książek szukając informacji o MVP. Czasami czytałem, że Prezenter zawiera logikę aplikacji natomiast Model jest jedynie pośrednikiem między tą logiką a bazą danych. Gdzie indziej przeczytałem definicję MVP, która sugeruje, że MVP i MVC to praktycznie to samo, poza różnicą związaną ze sposobem powiadamiania Widoku. Inna często wymienianą różnica: w MVC, to Model odpowiedzialny jest za powiadamianie Widoku, a w MVP, tą odpowiedzialność posiada Prezenter.

Poniżej fragment z książki "C# 6.0 i MVC 5" Krzysztof Żydzik, Tomasz Rak.

"Model View Presenter to wzorzec powstały na bazie wzorca MVC. We wzorcu MVP prezenter jest tym samym, czym kontroler we wzorcu MVC z jedną mała różnicą, w prezenterze zawiera się logika biznesowa. Dane nie są przekazywane bezpośrednio z modelu do widoku jak to ma miejsce w MVC. Prezener wysyła zapytanie do modelu, model zwraca dane do prezentera, prezenter przetwarza otrzymane dane i przekazuje do widoku."

To wszystko nie jest ani prawdą, ani nie prawdą. To jest nie do końca prawda i to też jest nie do końca nieprawda. Nie można porównywać wzorców MVC i MVP bez konkretnego rozdzielenia tych wzorców na warianty. Wzorzec MVC można zaimplementować w odmianie Passive lub Active. Moje zdanie jest takie, że te dwie odmiany wzorca MVC tak się od siebie różnią, że nie można mówić o wzorcu MVC nie doprecyzowując, którą odmianę mamy na myśli. Podobnie jest z wzorcem MVP. Ten też posiada dwie odmiany: Passive View oraz Supervising Controller.

Zauważyłem taką tendencję, że jeśli ktoś pisze lub mówi o MVC to w domyśle ma wersję Passive a gdy ktoś mówi o MVP to w domyśle mówi o Passive View. Taki skrót myślowy powoduje, że porównujemy te dwa wzorce parując ze sobą tylko po jednej z odmian. W moim rozumieniu porównanie MVC i MVP wymaga wykonania sześciu różnych porównań, jak poniżej:

Active MVC, Passive MVC, MVP Passive View, MVP Supervising Controller



5 komentarzy :

  1. Nie pisze się "w krótce", ale "wkrótce" :)
    Fajnie, że będzie coś po polsku w tym temacie. Będę śledził.

    OdpowiedzUsuń
  2. w moim rozumienie prezetner w MVP zawiera logike prezetnacyjna. Absolutnie nie powinien zawierac logiki biznesowej(to jest czesc modelu)

    OdpowiedzUsuń
  3. Poprawiłem na "wkrótce" :), dzięki.

    OdpowiedzUsuń
  4. Artur Ligmann, w moim rozumieniu również. Spłycenie Modelu do obiektu typu DTO jest błędem. Będę o tym pisać w kolejnych częściach.

    OdpowiedzUsuń
    Odpowiedzi
    1. Między innymi tutaj rozchodzi się o to, kto zarządza zmianą stanu Modelu. Zarówno w MVP jak i MVC, w zależności od odmian tych wzorców, stanem może zarządzać: sam Model, Kontroler lub Prezenter. Logika zawsze jest w Modelu.

      Usuń