MVVM i MVP

Celem rozwoju oprogramowania jest tworzenie rozwiązań odpowiadających potrzebom i problemom użytkowników i firm. Aby to osiągnąć, różne technologie i wzorce architektury, takie jak Model-View-ViewModel (MVVM) i Model-widok-prezenter (MVP) są używane.

Podobnie jak w przypadku wszystkiego, co jest produkowane, pierwszym krokiem jest etap planowania i projektowania. Proces projektowania oprogramowania może być specyfikacją opartą na preferowanym zestawie narzędzi technologicznych i może obejmować całą działalność, od koncepcji po planowanie, aż po implementację, aż po aktualizacje i modyfikacje.

Obejmuje on projekt architektoniczny niskiego poziomu i wysokiego poziomu, oparty na wybranych wzorcach architektury, i mapuje rozwiązania wielokrotnego użytku z wykorzystaniem wzorców projektowych.

Struktura aplikacji

Architektura oprogramowania definiuje strukturę aplikacji, która spełnia wymagania techniczne, operacyjne i użytkownika oraz odnosi się do sposobu organizacji i zarządzania kodem.

Decydowanie o architekturze aplikacji jest kluczowe, ponieważ nie jest łatwą, zmienną częścią aplikacji, która jest już opracowana; dlatego przed rozpoczęciem programowania należy zdecydować o wzorze architektonicznym.

Wzorce architektoniczne różnią się nieco od wzorców projektowych, ponieważ ich zakres jest znacznie szerszy, ponieważ zajmują się bardziej technicznymi problemami, takimi jak wydajność sprzętu i ograniczenia oraz wysoka dostępność. Przykładami różnych wzorców architektury są MVC, MVVM i MVP.

Z drugiej strony, wzorce projektowe są sformalizowanymi najlepszymi praktykami, które ułatwiają wielokrotne wykorzystanie rozwoju obiektowego i są łatwiejsze do utrzymania i zmiany niż architektura aplikacji.

Wzorce architektury

Kontroler widoku modelu (MVC) był jednym z pierwszych wzorów architektonicznych opracowanych dla aplikacji internetowych, zyskując popularność od połowy do końca lat dziewięćdziesiątych, szczególnie w społeczności Java.

Nowsze frameworki, takie jak Django dla Pythona i Railsów (Ruby on Rails), kładą duży nacisk na szybkie wdrażanie, dlatego MVC bierze udział w rynku jako duża atrakcja w architekturze.

Tradycyjnie, rozwój interfejsu użytkownika zawierał wiele kodów służących do obsługi skomplikowanej logiki, dlatego zaprojektowano wzorce architektury w celu zredukowania kodu na poziomie interfejsu użytkownika (UI), czyniąc go bardziej "czystym" i łatwiejszym w zarządzaniu.

Tak więc w przypadku wzorca MVC składa się aplikacja internetowa

• Model (dane)
• Widok (interfejs do przeglądania i manipulowania danymi)
• Kontroler (operacje i działania wykonywane na danych)

The Model obsługuje dane i logikę biznesową i są Nie zależności między Model i Kontroler lub Widok.

The Widok przedstawia dane użytkownikowi w obsługiwanym formacie i wymaganym układzie, a gdy Kontroler odbiera żądania użytkowników (w celu pobrania danych), wywołuje odpowiednie zasoby potrzebne do zrealizowania żądania.

Zastosuj ten wzorzec do budowy internetowego księgarni.

Użytkownicy mogą wyszukiwać, przeglądać, rejestrować i kupować książki, a także zarządzać ich profilami i listami książek. Gdy użytkownik kliknie na kategorię SCI-FI, wszystkie powiązane książki powinny być wyświetlane jako dostępne.

The Kontrolery zarządzać działaniami, które zarządzają książkami (lista, dodawanie, przeglądanie itp.). Może być ich wiele Kontrolery z jedną główną Kontroler "Kierowanie ruchem".

W tym przykładzie Kontroler nazywa się controller_books.php i Model (np. model_books.php) obsługuje dane i logikę związaną z książkami.

Wreszcie, różne Widoki będą wymagane, np. podczas dodawania książek do koszyka online lub podczas przeglądania szczegółów książki ze zdjęciami i recenzjami.

The controller_books.php odbiera akcję (żądanie użytkownika) od głównej Kontroler (na przykład. index.php). The controller_books.php analizuje żądanie i wywołuje model_books.php (dane), aby zwrócić listę książek SCI-FI.

Odpowiedzialność Model jest dostarczenie tych informacji przy użyciu dowolnej logiki, która została zastosowana (przy użyciu filtrów wyszukiwania). The Kontroler następnie bierze informacje i przekazuje je odpowiedniemu Widok (widok wyszukiwania, widok wydruku, widok szczegółów itp.) i informacje są prezentowane (za pośrednictwem Widok) do użytkownika, który zainicjował żądanie.

Jest to podstawa wzorca MVC, który ewoluował zmienność spawnującą wzorców architektury, takich jak Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchiczny Model-Widok-Kontroler (HMVC), i Adapter widoku modelu (MVA) itp.

Wzór MVP

Model-widok-prezenter (MVP)

The Wzór MVP istnieje już od jakiegoś czasu i jest odmianą MVC. Został zaprojektowany specjalnie do automatyzacji testów, gdzie celem było zwiększenie ilości kodu, który może być testowany za pomocą automatyzacji, a wzorzec rozwiązuje pewne problemy z warstwą prezentacji, izolując logikę biznesową od interfejsu użytkownika.

Ekran jest widokiem, dane, które wyświetla, to model, a prezenter łączy je razem.

MVP składa się z następujących elementów o odrębnych obowiązkach:

• Model (określa dane do wyświetlenia)
• Widok (wyświetla dane z modelu i kieruje zapytania użytkownika do prezentera).
• Prezenter (współdziała między widokiem a modelem i łączy je razem)

The Widok (strona internetowa) wyświetla i zarządza kontrolkami strony, przekazując zdarzenia (żądania użytkowników) do Prezenter zainicjowane w Widok.

The Prezenter reaguje na te zdarzenia, czytając i aktualizując Model żeby zmienić Widok i dlatego Prezenter odpowiedzialność to wiązać Model i Widok.

Po obejrzeniu MVC i MVP wzorce, wspólnota ma zarówno odrębne obowiązki dla każdego komponentu, jak i promuje separację między Widok (UI) i Model (dane). Istotne różnice między tymi wzorcami są bardziej widoczne w sposobie implementacji wzorców.

MVP może być złożonym wzorcem do zastosowania w zaawansowanych rozwiązaniach, ale z pewnością ma ogromne zalety, jeśli zostanie zaimplementowany jako dobrze zaprojektowane rozwiązanie, chociaż niekoniecznie będzie właściwym wyborem dla prostych rozwiązań.

Wzór MVVM

Model-View-ViewModel (MVVM)

The MVVM wzór został zaprojektowany specjalnie dla platform Windows Presentation Foundation (WPF) i Microsoft Silverlight i może być używany na wszystkich XAML [i] platformy.

WPF to system firmy Microsoft, który renderuje interfejsy użytkownika w programach opartych na systemie Windows i został po raz pierwszy wydany w.NET Framework 3.0.

MVVM został udoskonalony z MVC i w tym wzorze Widok jest aktywny z zachowaniem, zdarzeniami i powiązaniem danych oraz z Widok synchronizuje się z ViewModel (która umożliwia oddzielenie prezentacji i udostępnia metody i polecenia do zarządzania i manipulowania Model.

MVVM składa się z trzech głównych komponentów:

• Model (reprezentuje dane z walidacją i logiką biznesową)
• Widok (Widok jest odpowiedzialny za zdefiniowanie struktury, układu i wyglądu tego, co widzi użytkownik na ekranie.) Idealnie, widok jest zdefiniowany wyłącznie za pomocą XAML, z ograniczonym kodem źródłowym, który nie zawiera logiki biznesowej. powiązanie między Widok i ViewModel do displayenables synchronizujących Model i ViewModel z widokiem)
• ViewModel (oddziela widok od modelu i ujawnia metody i polecenia do manipulowania danymi (model).

The Widok odbiera dane z ViewModel (poprzez wiązanie danych i metody) oraz w czasie wykonywania Widok zmieni się podczas reagowania na zdarzenia w ViewModel.

The ViewModel pośredniczy między Widok i Model i obsługuje Widok logika. Interakcja z Model - pobieranie danych z Model i przedstawienie go Widok do wyświetlenia.

Te komponenty są od siebie odsprzężone, co umożliwia większą elastyczność pracy nad nimi niezależnie, izolowanie testów jednostkowych i wymienianie ich bez wpływu na żaden inny komponent.

Ta struktura pozwala Model i inne komponenty do niezależnej ewolucji, pozwalając programistom pracować równolegle nad różnymi aspektami rozwiązania. Na przykład, gdzie projektanci pracują nad Widok, po prostu generują próbki danych bez konieczności dostępu do innych komponentów. Ułatwia to łatwe przeprojektowanie interfejsu użytkownika jako Widok jest zaimplementowany w XAML.

Jak wcześniej wspomniano MVPproste rozwiązania nie wymagałyby architektury i wzorców projektowych, takich jak "Hello World!" jest zbyt proste, aby można było zastosować dowolny wzór; Jednak wraz z wprowadzeniem kolejnych funkcji, funkcji i komponentów zwiększa się złożoność aplikacji, a także ilość kodu, którym należy zarządzać.

W podsumowaniu

Od początku rozwoju interfejsu użytkownika wzorce projektowe stają się coraz bardziej popularne, aby proces tworzenia był łatwiejszy, aplikacje bardziej skalowalne i ułatwiające testowanie.

Zilustrowana różnica między wzorcami MVP i MVVM:

• Zarówno MVP i MVVM, Widok jest punktem wejścia do aplikacji
• W MVP, istnieje mapowanie jeden-do-jednego między Widok i Prezenter, w której MVVM, związek jest jeden do wielu między Widok i ViewModel.
• MVP jest używany głównie w aplikacjach Windows Forms i Windows Phone oraz MVVM jest przeznaczony dla Silverlight, WPF, Knockout / AngularJS, itp.