Wątek zablokowany 2018-06-22 22:03 przez somekind.

MVVM vs MVC

0

Witam serdecznie :) Mam kilka pytań odnośnie różnic między wzorcami MVVM i MVC. Generalnie w MVVM:

  • View - kontrolki, widok okna, XAML, to co widzi użytkownik
  • ViewModel - pola do bindowania z widokiem, zapytania do bazy danych wszystkie metody, commandy itd.
  • Model - nasza struktura danych np. baza danych, typy itd.

Jeżeli coś źle rozumiem bardzo proszę o poprawienie. Natomiast teraz pytanie - jaka jest różnica między MVVM i MVC? Generalnie MVC działa bardzo podobnie (chyba) tj. mamy widok czyli to co widzi użytkownik, model czyli jakaś struktura danych, i kontroler który powoływany jest do życia przez wklepanie odpowiedniego adresu url (tutaj działa routing). Generalnie wszystkie działanie takie jak np. połącz z bazą -> pobierz -> przekaż do widoku także realizuje kontroler?

0

Dość ciekawy i dobry artykuł porównujący różne wzorce architektury - http://www.codeproject.com/Articles/66585/Comparison-of-Architecture-presentation-patterns-M . Z mojego punktu widzenia to Ci się na początku przyda.

Zarówno MVVM jak i MVC są wzorcami architektury, mają one na celu zorganizowanie struktury aplikacji. MVC jest dość popularny w aplikacjach webowych, w przypadku platformy .NET mamy oczywiście ASP.NET MVC, dla MVVM jest on naturalnie stosowany z aplikacjami tworzonymi w technologii WPF.

2
Biały Terrorysta napisał(a):
  • ViewModel - pola do bindowania z widokiem, zapytania do bazy danych wszystkie metody, commandy itd.

żadne zapytania do bazy danych ani metody, tylko wywoływanie metod z "modelu"
viewmodel ma być "adapterem" między modelem a widokiem - ma tak przystosować / zagregować dane żeby były możliwe do zbindowania przez widok - np wywoływanie wszelkich metod formatujących tekst, sumujących dane z wielu modeli do jednego pola itp

2
Biały Terrorysta napisał(a):
  • Model - nasza struktura danych np. baza danych, typy itd.

Model to logika biznesowa/domenowa/dziedzinowa, nie struktura danych.

Generalnie MVC działa bardzo podobnie (chyba) tj. mamy widok czyli to co widzi użytkownik, model czyli jakaś struktura danych, i kontroler który powoływany jest do życia przez wklepanie odpowiedniego adresu url (tutaj działa routing).

Żadnego urla, adresu ani routingu nie musi być. Można napisać konsolową aplikację zgodną z MVC. Kontroler po prostu obsługuje żądania użytkownika i przekazuje je do modelu (który jest warstwą, nie klasą), a z drugiej strony decyduje o tym, który widok użytkownikowi wyświetlić. Dlatego jest dobry dla aplikacji webowych, bo nie przechowuje żadnego stanu między żądaniami użytkownika.
Natomiast ViewModel w MVVM zawiera więcej logiki bo sam w sobie odpowiada za dwustronną komunikację między widokiem a modelem, trzyma ich stan, potrafi śledzić zmiany tego, co się zmieniło.

Generalnie wszystkie działanie takie jak np. połącz z bazą -> pobierz -> przekaż do widoku także realizuje kontroler?

Nie, za połączenia z bazą odpowiada warstwa dostępu do danych, obrobienie ich do czytelnej postaci to zadanie warstwy aplikacji (obie są elementami modelu), a kontroler jest gdzieś tam na końcu dopiero.

mariano901229 napisał(a):

Zarówno MVVM jak i MVC są wzorcami architektury, mają one na celu zorganizowanie struktury aplikacji.

Nie tyle architektury, co warstwy prezentacji. Oba te wzorce odpowiadają na pytanie jak powiązać interfejs użytkownika z resztą aplikacji, nie jak zaprojektować wszystkie warstwy całej aplikacji.

1

Dodając do tego, co napisał @somekind: MVVM i MVC dotyczą nieco innych aspektów architektury aplikacji i nie ma najmniejszego problemu, żeby stosować oba wzorce jednocześnie. View do wyświetlenia danych (zero jakiejkolwiek logiki), ViewModel do dostarczenia odpowiednio sformatowanych/zagregowanych danych do View, Model do dostarczenia danych do Controller'a/ViewModelu, Controller do spięcia wszystkiego w całość. Ponadto warstwa Serwisów, która będzie używana przez kontroler (najlepiej za pośrednictwem interfejsów i DI poprzez kontener IoC), a która będzie realizować logikę biznesową i dostarczać lub przyjmować wypełnione danymi Modele do/z Controller'ów.
Kontroler tylko spina klocki w całość, nic nie waliduje, nie łączy się z bazą danych, nie implementuje logiki biznesowej (chyba, że mamy na myśli wywołanie odpowiednich metod serwisów w odpowiedniej kolejności).

0
somekind napisał(a):

Nie tyle architektury, co warstwy prezentacji. Oba te wzorce odpowiadają na pytanie jak powiązać interfejs użytkownika z resztą aplikacji, nie jak zaprojektować wszystkie warstwy całej aplikacji.

MVC może występować, jako architektóra oraz wzorzec projektowy. W drugiej wersji view oraz kontroler jest traktowany jako odzielna warstwa UI, której priorytetem jest rysowanie elementów graficznych. Dlatego w MVC dodatkowo jest stosowany ViewModle aby odzielić te dwie warstwy, czego większość ludzi nie rozumie.

0
ŁF napisał(a):

(najlepiej za pośrednictwem interfejsów i DI poprzez kontener IoC),

Dlaczego najlepiej za pośrednictwem interfejsów ?

Model do dostarczenia danych do Controller'a/ViewModelu, Controller do spięcia wszystkiego w całość

Dlaczego do Controller'a/ViewModelu? Niby dlaczego nie mogę w modelu mapować danych bezpośrednio na ViewModel ? ;)

View do wyświetlenia danych (zero jakiejkolwiek logiki)

A co z logiką do wyświetlania danych ;) ?

Kontroler tylko spina klocki w całość

Dlaczego spina? Moim zdaniem on tylko rozpina... ;)

0
Enter Name napisał(a):

Dlaczego najlepiej za pośrednictwem interfejsów ?

A dlaczego nie? ;-) Alternatywą jest bezpośrednie wskazanie na implementującą funkcjonalność klasę, co czyni IoC bezsensownym, albo klasy abstrakcyjne. Standardem z tego co się orientuję są jednak interfejsy. Masz jakąś alternatywę? Podaj, podyskutujemy.

Model do dostarczenia danych do Controller'a/ViewModelu, Controller do spięcia wszystkiego w całość

Dlaczego do Controller'a/ViewModelu? Niby dlaczego nie mogę w modelu mapować danych bezpośrednio na ViewModel ? ;)

Bo gubisz warstwę abstrakcji i np. przypinasz się na stałe do ORM. Prawda jest taka, że możesz napisać kod jak chcesz i możesz sobie zwracać viewmodele nawet bezpośrednio z repozytorium. Wszystko kwestią tego jak duży jest projekt, czy wybrane rozwiązania będą się odpowiednio skalować i czy po kilku latach nie okaże się, że całość trzeba przepisać...

View do wyświetlenia danych (zero jakiejkolwiek logiki)

A co z logiką do wyświetlania danych ;) ?

Grubsze sprawy na poziomie kontrolera, reszta w VM albo w mapperze, duperele w view. To nie są rygorystyczne zasady, nikt Ci ręki nie utnie jak zrobisz inaczej. Jednak uważam, że umieszczenie zbyt wielu rzeczy w warstwach, do których te rzeczy nie są przeznaczone powoduje, że projekt robi się ciężki do utrzymania.

1 użytkowników online, w tym zalogowanych: 0, gości: 1