Model–widok–widokmodel - Model–view–viewmodel

MVVMPatern.png

Model–view–viewmodel ( MVVM ) to architektoniczny wzorzec oprogramowania, który ułatwia oddzielenie rozwoju graficznego interfejsu użytkownika ( widoku ) – czy to za pomocą języka znaczników, czy kodu GUI – od rozwoju logiki biznesowej lub back- logika końca ( model ), aby widok nie był zależny od konkretnej platformy modelu. ViewModel z MVVM jest konwerter wartość, co oznacza, ViewModel jest odpowiedzialny za wystawienie (konwersji) do obiektów danych z modelu w taki sposób, że obiekty są łatwo zarządzany i przedstawione. Pod tym względem model widoku jest bardziej modelem niż widokiem i obsługuje większość, jeśli nie całą logikę wyświetlania widoku. Viewmodel może implementować wzorzec mediatora , organizując dostęp do logiki zaplecza wokół zestawu przypadków użycia obsługiwanych przez widok.

MVVM jest odmianą wzorca projektowego Model prezentacji Martina Fowlera . Został wynaleziony przez architektów Microsoft, Kena Coopera i Teda Petersa, specjalnie w celu uproszczenia sterowanego zdarzeniami programowania interfejsów użytkownika. Wzorzec został włączony do Windows Presentation Foundation (WPF) ( system graficzny Microsoft .NET ) i Silverlight (pochodna aplikacji internetowej WPF). John Gossman, jeden z architektów Microsoft WPF i Silverlight, ogłosił MVVM na swoim blogu w 2005 roku.

Model-view-viewmodel jest również określany jako model-view-binder , szczególnie w implementacjach nie obejmujących platformy .NET. ZK ( framework aplikacji internetowej napisany w Javie ) i KnockoutJS ( biblioteka JavaScript ) wykorzystują model–widok–binder.

Składniki wzorca MVVM

Model
Model odnosi się do modelu domeny , który reprezentuje zawartość stanu rzeczywistego (podejście zorientowane obiektowo) lub do warstwy dostępu do danych , która reprezentuje zawartość (podejście zorientowane na dane).
Pogląd
Podobnie jak we wzorcach model–widok–kontroler (MVC) i model–widok–prezenter (MVP), widok to struktura, układ i wygląd tego, co użytkownik widzi na ekranie. Wyświetla reprezentację modelu i odbiera interakcję użytkownika z widokiem (kliknięcia myszą, dane wejściowe z klawiatury, gesty stukania ekranu itp.) i przekazuje ich obsługę do modelu widoku poprzez powiązanie danych (właściwości, wywołania zwrotne zdarzeń itp.), który jest zdefiniowany w celu połączenia widoku i modelu widoku.
Zobacz model
Model widoku jest abstrakcją widoku uwidaczniającego właściwości i polecenia publiczne. Zamiast kontrolera wzorca MVC lub prezentera wzorca MVP, MVVM ma binder , który automatyzuje komunikację między widokiem a jego powiązanymi właściwościami w modelu widoku. Model widoku został opisany jako stan danych w modelu.
Główną różnicą między modelem widoku a prezenterem we wzorcu MVP jest to, że prezenter ma odwołanie do widoku, podczas gdy model widoku nie. Zamiast tego widok bezpośrednio wiąże się z właściwościami w modelu widoku w celu wysyłania i odbierania aktualizacji. Aby działać wydajnie, wymaga to technologii wiązania lub generowania kodu wzorcowego w celu wykonania wiązania.
Spoiwo
Dane deklaratywne i powiązanie poleceń są niejawne we wzorcu MVVM. W stosie rozwiązań firmy Microsoft spinaczem jest język znaczników o nazwie XAML . Spoiwo zwalnia programistę z obowiązku pisania logiki boiler-plate w celu synchronizacji modelu widoku i widoku. W przypadku implementacji poza stosem Microsoft obecność deklaratywnej technologii wiązania danych jest tym, co umożliwia ten wzorzec, a bez bindera zwykle używa się zamiast tego MVP lub MVC i trzeba napisać więcej boilerplate’u (lub wygenerować go za pomocą innego narzędzia ).

Racjonalne uzasadnienie

MVVM został zaprojektowany w celu usunięcia praktycznie całego kodu GUI („ kodu związanego ”) z warstwy widoku za pomocą funkcji powiązania danych w WPF (Windows Presentation Foundation), aby lepiej ułatwić oddzielenie rozwoju warstwy widoku od reszty wzorca. Zamiast wymagać od programistów środowiska użytkownika (UX) pisania kodu GUI, mogą używać języka znaczników frameworka (np. XAML ) i tworzyć powiązania danych z modelem widoku, który jest pisany i utrzymywany przez programistów aplikacji. Rozdzielenie ról pozwala interaktywnym projektantom skupić się na potrzebach UX, a nie na programowaniu logiki biznesowej. Warstwy aplikacji można zatem opracowywać w wielu strumieniach roboczych, aby uzyskać wyższą produktywność. Nawet gdy jeden programista pracuje nad całą bazą kodu, właściwe oddzielenie widoku od modelu jest bardziej produktywne, ponieważ interfejs użytkownika zazwyczaj zmienia się często i późno w cyklu rozwoju w oparciu o opinie użytkowników końcowych.

Wzorzec MVVM próbuje uzyskać obie korzyści wynikające z separacji rozwoju funkcjonalnego zapewnianego przez MVC, jednocześnie wykorzystując zalety powiązań danych i struktury poprzez powiązanie danych tak blisko czystego modelu aplikacji, jak to tylko możliwe. Wykorzystuje spinacz, model widoku i funkcje sprawdzania danych w warstwach biznesowych w celu walidacji danych przychodzących. W rezultacie model i framework sterują jak największą liczbą operacji, eliminując lub minimalizując logikę aplikacji, która bezpośrednio manipuluje widokiem (np. za kodem).

Krytyka

John Gossman skrytykował wzorzec MVVM i jego zastosowanie w określonych zastosowaniach, stwierdzając, że MVVM może być „przesadą” podczas tworzenia prostych interfejsów użytkownika. Uważa, że ​​w przypadku większych aplikacji uogólnienie modelu widoku z góry może być trudne, a wiązanie danych na dużą skalę może prowadzić do obniżenia wydajności.

Realizacje

Platformy .NET

Frameworki JavaScript

Zobacz też

Bibliografia

Zewnętrzne linki