Lubię o tym myśleć w ten sposób:
Widoki, jak mówisz, są głupie. Josh Smith, autor przełomowego i często powiązanego artykułu MSDN na temat MVVM, powiedział, że poglądy to „ubrania, które noszą dane”. Widoki w rzeczywistości nigdy nie zawierają danych ani bezpośrednio nimi manipulują, są po prostu powiązane z właściwościami i poleceniami modeli widoków.
Modele to obiekty modelujące domenę aplikacji , tak jak w przypadku obiektów biznesowych. Czy Twoja aplikacja to sklep muzyczny? Być może obiektami modelowymi będą artyści, albumy i piosenki. Czy Twoja aplikacja jest przeglądarką schematów organizacyjnych? Być może obiektami modelu będą menedżerowie i pracownicy. Te obiekty modelu nie są powiązane z żadnym rodzajem renderowania wizualnego i nie są nawet bezpośrednio związane z aplikacją, w której je umieszczasz - obiekty modelu powinny mieć sens same w sobie jako rodzina obiektów, które reprezentują jakiś rodzaj domeny. Warstwa modelu zazwyczaj zawiera również takie elementy, jak akcesory usług.
To prowadzi nas do Viewmodels. Czym oni są? Są to obiekty modelujące aplikację GUI, co oznacza, że zapewniają dane i funkcje do wykorzystania przez widoki. To one definiują strukturę i zachowanie faktycznie budowanej aplikacji. W przypadku obiektów modelu domeną jest dowolna wybrana domena (sklep muzyczny, przeglądarka schematów organizacyjnych itp.), Ale w przypadku modelu widoku domena jest aplikacją graficzną. Twoje modele widoku będą hermetyzować zachowanie i dane wszystkiego, co robi Twoja aplikacja. Będą ujawniać obiekty i listy jako właściwości, a także takie rzeczy, jak Polecenia. Polecenie to po prostu zachowanie (w najprostszym przypadku wywołanie metody) zawinięte w obiekt, który je przenosi - ta idea jest ważna, ponieważ widoki są sterowane przez wiązanie danych, które dołącza kontrolki wizualne do obiektów. W MVVM nie dajesz przyciskowi metody obsługi kliknięcia,
Dla mnie najbardziej zagmatwane były następujące elementy:
- Mimo że modele widoków są modelami aplikacji graficznej, nie odwołują się bezpośrednio ani nie używają pojęć wizualnych. Na przykład nie chcesz, aby odwołania do formantów systemu Windows w modelach widoku były wyświetlane w widoku. ViewModels po prostu ujawniają dane i zachowania kontrolkom lub innym obiektom, które zostaną z nimi powiązane. Na przykład - czy masz widok zawierający ListBox? Twój Viewmodel prawie na pewno będzie zawierał jakąś kolekcję. Czy Twój widok ma przyciski? Twój Viewmodel prawie na pewno będzie zawierał jakieś polecenia.
- Istnieje kilka rodzajów obiektów, które można uznać za „modele widoków”. Najłatwiejszy do zrozumienia rodzaj modelu widoku to taki, który bezpośrednio reprezentuje kontrolkę lub ekran w relacji 1: 1, tak jak w przypadku „screen XYZ ma pole tekstowe, pole listy i trzy przyciski, więc model widoku wymaga ciągu, kolekcji, i trzy polecenia. " Innym rodzajem obiektu, który mieści się w warstwie modelu widoku, jest otoka wokół obiektu modelu, która nadaje mu zachowanie i sprawia, że jest on bardziej użyteczny w widoku - w tym miejscu można zapoznać się z koncepcjami „grubych” i „cienkich” warstw modelu widoku. „Cienka” warstwa modelu widoku to zestaw modeli widoków, które eksponują obiekty modelu bezpośrednio na widoki, co oznacza, że widoki wiążą się bezpośrednio z właściwościami obiektów modelu. Może to działać w przypadku prostych widoków tylko do odczytu, ale co, jeśli chcesz, aby zachowanie było powiązane z każdym obiektem? Nie chcesz tego w modelu, ponieważ model nie jest powiązany z aplikacją, jest powiązany tylko z Twoją domeną. Możesz umieścić go w obiekcie, który otacza obiekt modelu i oferuje bardziej przyjazne dla powiązań dane i zachowania. Ten obiekt otoki jest również uważany za model widoku, a posiadanie ich skutkuje „grubszą” warstwą modelu widoku, w której widoki nigdy nie są bezpośrednio powiązane z niczym w klasie modelu. Kolekcje będą zawierać modele widoków, które zawijają modele, a nie tylko same modele. Możesz umieścić go w obiekcie, który otacza obiekt modelu i oferuje bardziej przyjazne dla powiązań dane i zachowania. Ten obiekt otoki jest również uważany za model widoku, a posiadanie ich skutkuje „grubszą” warstwą modelu widoku, w której widoki nigdy nie są bezpośrednio powiązane z niczym w klasie modelu. Kolekcje będą zawierać modele widoków, które zawijają modele, a nie tylko same modele. Możesz umieścić go w obiekcie, który otacza obiekt modelu i oferuje bardziej przyjazne dla powiązań dane i zachowania. Ten obiekt otoki jest również uważany za model widoku, a posiadanie ich skutkuje „grubszą” warstwą modelu widoku, w której widoki nigdy nie kończą się bezpośrednio powiązaniem z niczym w klasie modelu. Kolekcje będą zawierać modele widoków, które zawijają modele, a nie tylko same modele.
Królicza dziura sięga głębiej - istnieje wiele idiomów, które należy wymyślić, takich jak ValueConverters, które sprawiają, że MVVM działa, i jest wiele do zastosowania, gdy zaczynasz myśleć o takich rzeczach, jak Blendability, testowanie i jak przekazywać dane w aplikacji i upewnić się, że każdy model widoku ma dostęp do potrzebnego zachowania (w tym miejscu pojawia się zastrzyk zależności), ale mam nadzieję, że powyższe jest dobrym początkiem. Kluczem jest myślenie o wizualizacjach, domenie oraz strukturze i zachowaniu rzeczywistej aplikacji jako o trzech różnych rzeczach.