Transcript 3. MVVM - Opis wzorca, przykłady użycia

MVVM
Model – View - ViewModel
Opis wzorca, przykłady użycia
Wzorce architektoniczne
Wzorce architektoniczne to uznane i sprawdzone
sposoby rozwiązania danego problemu z zakresu
architektury oprogramowania. Wzorce te określają
ogólną strukturę danego systemu, elementy z
jakich
się
składa,
zakres
funkcjonalności
realizowany przez dany element jak również
zasady komunikacji pomiędzy poszczególnymi
elementami.
Czego oczekujemy od kodu ?
 Przejrzystości
 Spójności
 Dobrej testowalności
MVVM, co to takiego..
Problem: Interfejs użytkownika w waszej aplikacji jest bardzo
skomplikowany, a poszczególne ekrany mocno ze sobą powiązane.
Rozwiązanie: Oddzielenie ekranów interfejsu użytkownika
od stojącej za nimi logiki poprzez dodanie klasy
ViewModel, która zawierać będzie całą skomplikowaną
logikę i wiedzę o zależnościach, oraz dostarczy dane
(poprzez właściwości) dla ekranu (View) tak, aby ten był
zawsze aktualny.
Tym właśnie po krótce jest MVVM – niczym
mniej, niczym więcej. Wszystko inne to
szczegóły implementacji.
MVVM w praktyce - podstawowe pojęcia
Model
View
ViewModel
Model
Model jest odpowiedzialny za ekspozycję danych w
sposób łatwo przetwarzalny przez WPF. Klasa ta musi
implementować interfejs INotifyPropertyChanged i\lub
INotifyCollectionChanged. W przypadku gdy mamy do
czynienia z dużymi porcjami danych, których pobieranie
jest kosztowną operacją, zaleca się pobieranie danych
partiami i używanie metod asynchronicznych tak, by nie
blokować wątku interfejsu użytkownika. W klasie Model
umieszka się także mechanizmy pilnujące aktualności
wystawianych danych. Klasa ta może skupiać dane z wielu
źródeł i ze względu na swoją budowę jest łatwo testowalna
(chodzi o testy automatyczne).
Model – przykład kodu
View
View stanowi właściwy Interfejs użytkownika
stojący za widokiem w aplikacji. W omawianym
wzorcu chodzi o to aby DataContext takiego
widoku „nakarmić” przynależną mu klasą
ViewModel, co pozwoli na łatwe bindowanie
danych do poszczególnych elementów widoku.
Idealnym rozwiązaniem zgodnie z wzorcem MVVM
byłoby zaimplementowanie View w formie
czystego XAML (bez code behind).
View – przykład kodu
View – code behind
Jak widać, mamy tylko inicjalizację kontrolki, choć
akurat w tym przypadku powinien być jeszcze
dołączony DataContext, ale w przykładowym
projekcie zrobiono to w oknie „matce”.
ViewModel
ViewModel stanowi model dla widoku w aplikacji.
Klasa ta wystawia zarówno dane jak i zachowania
(implementowane zazwyczaj jako komendy)
wymagane przez widok (View). Klasa ViewModel
jest klasą specyficzną dla danego widoku w
aplikacji ale nie zawiera żadnych kontrolek WPF i
referencji do tego widoku - słowem nie jest
„świadoma” widoku, który z niej korzysta. Takie
podejście zapewnia pełną separację tych klas przy
jednoczesnej silnej zależności i czyni z klasy
ViewModel klasę łatwo testowalną.
ViewModel – przykład kodu
Efekt końcowy połączenia trzech
powyższych klas.
Graf MVVM
Dlaczego właśnie WPF/Silverlight
Przykładowe interfejsy i klasy ułatwiające databinding:
 INotifyPropertyChanged: interfejs używany aby poinformować
odbiorów o zmianie wartości danego obiektu. W MVVM zwykle
implementowany przez Model, który w ten sposób powiadamia
ViewModel i View o tym, że dane przez niego wystawiane się zmieniły.
 ObservableCollection: klasa reprezentująca dynamiczną kolekcję
danych z wbudowanymi powiadomieniami w przypadku edycji,
dodawania, usuwania, a nawet całkowitego odświeżenia elementów
kolekcji.
 ICommand: interfejs dla komend, które łatwo dają się bindować pod
kontrolki WPF – koniec ze zdarzeniami. Szczególną implementacją
tego interfejsu jest stworzoną specjalnie na potrzeby MVVM
RelayCommand.
 IValueConverter: interfejs pozwalający na dynamiczną konwersję
danych bindowanych do View.
Komunikacja między widokami
 Zdarzenia: to dosyć popularne rozwiązanie, które
można znaleźć w wielu implementacjach wzorca MVVM.
Jego zaletą jest łatwa implementajca. Po każdej operacji
zostaje uruchomione zdarzenie i wszystkie podpięte pod
nie ViewModele zaktualizują się zgodnie z jego
rodzajem.
 Mediatory: to w zasadzie cały wzorzec wspomagający
MVVM – w dużym skrócie tworzymy dodatkową klasę do
której referencje będą miały potrzebujące komunikacji
ViewModele. Klasa ta może rejestrować wiadomości
(zdarzenia) i udostępnia „nasłuch” podłączonym do niej
klasom.
Zalety
 Wyraźny podział na View (UI właściwe) i ViewModel
(łatwo testowalna logika i dane do widoku) – z jednej
strony łatwo testować, z drugiej łatwo projektować widoki
(Expression Blend)
 Koniec z duplikacją danych – do widoku przypinane są
dane bezpośrednio z modeli, brak wszechobecnych
zdarzeń – wszystko dzieje się „samo” ;)
 ViewModel w połączeniu z dwustronnym bindingiem
umożliwia modyfikację danych zasilanych przez Modele
 Klasa ViewModel umożliwia agregację kilku modeli w
taki sposób, aby wyświetlanie danych było jak najmniej
problematyczne, przy czym jest od modeli niezależny.
 Doskonale komponuje się z technologią WPF i pozwala
w pełni wykorzystać jej możliwości.
Wady
 Aby obsłużyć jeden widok należy utworzyć wiele klas co
sprawia że projekt robi się „duży”.
 Problemy z komunikacją – zgodnie ze wzorcem
ViewModel nie może wiedzieć o View, które nie powinno
mieć z kolei code behind. Zdarza się że pewne rzeczy
dużo łatwiej zaprogramować naginając te zasady.
 Na potrzeby MVVM powstało wiele klas bazowych,
takich jak ViewModelBase, czy właśnie RelayCommand
– bez dedykowanego frameworka programista zdany
jest na siebie (i ręczne dodawanie potrzebnych klas lub
dopisywanie wszystkiego samemu).
Warto pamiętać..
Toolkity




MVVM Toolkit (Microsoft) to bardzo lekka bilbioteka zawierająca
szablony w Visual Studio, które wspierają początkujących w tym wzorcu.
Prism (Microsoft p&p) jest frameworkiem dostarczającym więcej niż
tylko wsparcie dla wzorca MVVM. Glównym celem tego projektu jest
pomagać w budowaniu modułowych aplikacji tak w WPFie jak i
Silverlighcie. Zbyt złożony dla początkujących i zbyt rozbudowany dla
tych, którzy potrzebują czystego wzorca.
WPF Application Framework (WAF) to kolejny lekki framework, który
pomaga w tworzeniu aplikacji WPF z wykorzystaniem wzorca MVVM.
Jego wadą jest to, że wspiera tylko WPF. Działa w inny sposób niż
większość frameworków MVVM – zawiera kontrolery (Controllers). Klasy
te są odpowiedzialne za przepływ danych w aplikacji i pełnią rolę
mediatorów pomiędzy poszczególnymi ViewModelami.
MVVM Light Toolkit uważany za jeden z lepszych lekkich toolkitów w
temacie. Znacząco poprawia pracę ze wzorcem MVVM a jednocześnie
pozostawia użytkownikowi dużo swobody w projektowaniu. Posiada silne
wsparcie dla Silverlighta i Blendability.