MVP vs MVC vs MVVM vs VIPER. Co jest lepsze dla rozwoju iOS?

Tak samo, jak każdy dom ma solidną piwnicę, każdy projekt oprogramowania, ma architekturę oprogramowania, na której jest zbudowany, a każdy projekt ma własną strukturę aplikacji. Rodzaje wzorców architektonicznych mogą się różnić, ale są 4 najczęściej używane - te, które cały świat IT nieustannie krytykuje, ale używa jednocześnie: MVC, MVP, MVVM i Viper (ostatni jako wzorzec architektury iOS) . Porównanie tych wzorców i wybór lepszego dopasowania do przypadku każdego projektu napisanego przez Swift zostanie omówione w dalszej części tego artykułu.

Zgodnie z chronologicznym porządkiem rzeczy, po pojawieniu się pierwszych wzorców projektowania oprogramowania, wspólne problemy tych wzorców architektury rozwoju ios nie trwały długo.

Na przykład problem komunikacji serwer-klient – ​​jak jeden oddziałuje na drugi? Lub inny - problem oddzielenia logiki biznesowej aplikacji od logiki wewnątrz aplikacji; jak ten powinien działać pod względem architektury aplikacji? Dzięki nim świat widziały różne wzorce projektowe dla różnych warstw architektury; najbardziej znane z nich to:

- Wzór projektowy Singleton.

Ten wzorzec pozwala na zastosowanie jednej klasy tylko do jednego obiektu, a ta opcja jest przydatna, gdy ograniczona liczba instancji (lub tylko jedna instancja) jest zatwierdzona przez system.

- Wzorzec projektowy dekoratora.

W przeciwieństwie do singletona ten wzorzec (zwany również Wrapper razem ze wzorcem Adapter) pozwala na dodanie określonego zachowania do pojedynczego obiektu (statycznie lub dynamicznie), a wszystko to bez wpływu na zachowanie innych obiektów. jeden dzieli klasę.

- Wzorzec projektowy mostu.

Po raz pierwszy wprowadzony przez znaną Grupę Czterech – autorów książki „Wzorce projektowe”, ten wzorzec architektoniczny „wykorzystuje enkapsulację, agregację i może wykorzystywać dziedziczenie do rozdzielania obowiązków na różne klasy. programowanie staje się bardzo przydatne, ponieważ zmiany w kodzie programu można łatwo wprowadzać przy minimalnej wiedzy o programie. [Źródło: Wiki]

Pomimo tego, że te wzorce są dość różne, wspólne problemy twórców kodu pojawiły się z każdym z nich; na przykład z „masywnością” Singletona. Singleton jest zbyt globalny, ponieważ zależności twojego kodu są ukryte głęboko w twojej aplikacji, zamiast być ujawniane w interfejsach. Dlatego w procesie tworzenia oprogramowania stale pojawiają się nowe wzorce.

4 najczęściej używane wzorce to MVC, MVP, MVVM i VIPER (głównie dla iOS).

Opracowane w tej samej kolejności, co wymieniono, wszystkie mają swoje zalety i wady, powodując liczne spory o to, gdzie zastosować każdy z nich. Zwrócenie nieco większej uwagi na najlepsze praktyki, które wdrażają, może nieco wyjaśnić.

Wzór MVC

Dziadek wszystkich wzorców oprogramowania, po raz pierwszy wprowadzony na początku lat 70. przez norweskiego informatyka Trygve Reenskauga, Moduł - Widok - Kontroler, powszechnie znany jako MVC, jest jednym z pierwszych podejść wzorcowych programowania obiektowego.

Część View odpowiada za wyświetlenie wszystkiego dla użytkownika systemu (interfejsy aplikacji mobilnej, webowej itp.). Model jest generalnie odpowiedzialny za bazy danych, podmioty gospodarcze i resztę danych. Z kolei Kontroler reguluje pracę Modelu, dane dostarczane do bazy danych, wyświetlanie ze wspomnianej bazy do części Widok i odwrotnie.

Jakkolwiek uniwersalny może być model MVC, dwaj najwięksi konkurenci - Apple i Google mają swoje własne wzorce reprezentujące system Model - Widok - Kontroler. Problem w systemie Apple polega na ścisłym połączeniu między częściami widoku i kontrolera, prawie do tego stopnia, że ​​łączy widok i kontroler i pozostawia część modelu oddzieloną.

W konsekwencji prowadzi to do słabego procesu testowania - tylko Model może być zbadany, V&C (ze względu na ścisłe połączenie, które mają) nie może być w ogóle przetestowany.

Solidne połączenie między segmentami Kontrolera i Widoku okazało się naprawdę „niezdrowe”, jeśli chodzi o oprogramowanie, więc wkrótce świat ujrzał nowy wzorzec.

Wzór MVP.

Wielu z nas słyszało ten skrót w kontekście Minimum Viable Product, ale w kontekście inżynierii oprogramowania oznacza to coś innego. Wzorzec prezentera widoku modelu ma kilka kluczowych punktów, tworząc ogromną przepaść między nim a MVC:

Model MVP

• Widok jest luźniej powiązany z modelem. Prezentujący jest odpowiedzialny za powiązanie Modelu z Widokiem.

• Łatwiejsze testowanie jednostkowe, ponieważ interakcja z widokiem odbywa się za pośrednictwem interfejsu.

• Zwykle widok do prezentera = mapowanie jeden do jednego. Złożone widoki mogą mieć wielu prezenterów.

Wzór MVC

• Kontrolery są oparte na zachowaniach i mogą być udostępniane między widokami

• Może być odpowiedzialny za określenie, który widok ma być wyświetlany
  [Źródło: Infragistyka]

W tym układzie funkcje Modelu pozostają takie same; Prezenter odpowiada odpowiednio za logikę biznesową. Szczególnie interesująca jest część V - podzielona na dwie części View i View Controller, które są upoważnione do interakcji. Gdy pojawia się pytanie MVVM vs MVC, system tego typu rozwiązuje problem „ciężkiego uzależnienia” trybów widoku i kontrolera, które miały we wzorcu MVC.

W tym przypadku rozwiązywana jest również przeszkoda testowa, ponieważ części Model, Widok z interakcją z użytkownikiem oraz Prezenter – wszystkie te elementy można przetestować.
Istniejąca jeszcze niedogodność leży po stronie prezentera - jednak zbyt duża, ale uwzględnia całą istniejącą logikę biznesową. Dlatego do gry wszedł kolejny akt, nazwany…

Wzorzec MVVM

Wzorzec architektoniczny oprogramowania Model-View-ViewModel został stworzony w 2005 roku przez Johna Gossmana, jednego z architektów Microsoftu. Trzy podstawowe elementy modelu MVVM to odpowiednio:
Model to „implementacja modelu domeny aplikacji, która obejmuje model danych wraz z logiką biznesową i walidacji. Przykłady obiektów modelowych obejmują repozytoria, obiekty biznesowe, obiekty transferu danych (DTO), zwykłe stare obiekty CLR (POCO) oraz wygenerowane obiekty encji i proxy”. [Źródło: Microsoft]

Widok to znowu wszystko, co użytkownik jest w stanie zobaczyć – układ, struktura i wygląd wszystkiego na ekranie. Zasadniczo w aplikacji byłaby to strona aplikacji. View pobiera i wysyła aktualizacje tylko do ViewModel, wyłączając całą komunikację między tą częścią a samym modelem.

ViewModel ma być „łańcuchem łączącym” pomiędzy komponentami systemu View i Model, a jego główną funkcją jest obsługa logiki View. Zazwyczaj model widoku współdziała z modelem, wywołując metody w klasach modelu. Model widoku następnie udostępnia dane z modelu w formie, z której widok może łatwo korzystać, jak stwierdza firma Microsoft.

Główną różnicą między MVC i iOS MVVM jest to, że wzorzec dystrybucji MVVM jest lepszy niż we wcześniej wymienionym MVC, ale w porównaniu do MVP jest również znacznie przeciążony. Testowanie ma tutaj szczególne znaczenie, bo pisząc po prostu kod nie można zagwarantować, że cały projekt będzie działał poprawnie - testy, na dobrą sprawę, pomagają upewnić się, że tak będzie.

Kolejna ewolucja wzorców architektonicznych została niedawno wydana i jest obecnie najświeższym podejściem do architektury oprogramowania.

Architektura iOS VIPER

Poszukując najlepszego rozwiązania architektonicznego do dostarczenia, programiści iOS na całym świecie natknęli się na tak zwane podejście „czystej architektury”, wprowadzone przez Wujka Boba na Clean Coders - dobrze znanej platformie zapewniającej sesje szkoleniowe dla specjalistów oprogramowania na całym świecie.

Czysta Architektura dzieli logiczną strukturę aplikacji na kilka poziomów odpowiedzialności. Z kolei ta „separacja” rozwiązuje problemy ze ścisłymi zależnościami i zwiększa dostępność testowania na wszystkich poziomach.

VIPER dla rozwoju ios

VIPER to realizacja Czystej Architektury dla aplikacji zbudowanych na iOS. Wspólną zasadą dla wszystkich nazw wzorców jest również backronim dla widoku, interakcji, prezentera, jednostki i routingu. Każda z części VIPER odpowiada za określony element, a w szczególności:

1. Widok jest odpowiedzialny za odzwierciedlenie działań wykonywanych przez użytkownika za pomocą interfejsu

2. Obowiązki prezentera w ramach wzorca VIPER są dość ograniczone - otrzymuje on aktualizacje od Entity, ale nie wysyła do niego żadnych danych;

3. Interactor to ta część systemu, która faktycznie odpowiada Entities. Ten schemat działa w następującym kierunku: prezenter informuje Interactor o zmianach w modelu widoku, następnie Interactor kontaktuje się z częścią Entity, a wraz z danymi otrzymanymi od Entity Interactor wraca do prezentera, który nakazuje View, aby odzwierciedlić go dla użytkownika. Wszystkie modele danych, wszystkie podmioty i wszystkie strony internetowe są połączone z częścią Interactor.

4. Byt składa się z obiektów kontrolowanych przez Interactor (tytuły, treść itp.). Nigdy nie wchodzi w bezpośrednią interakcję z Prezenterem, tylko poprzez I-part.

5. Routing (lub model szkieletowy, jak to się czasem nazywa) jest odpowiedzialny za nawigację między wszystkimi ekranami i zasadniczo za routing. Model szkieletowy kontroluje obiekty UIWindow, UINavigationController i tak dalej.

Zwłaszcza w systemie architektonicznym iOS wszystko opiera się na frameworku zwanym UIkit, który zawiera wszystkie komponenty Apple MVC, ale bez ścisłego połączenia, które wcześniej doprowadzało programistów do szaleństwa.

Moduł VIPER jest równie korzystny, jeśli chodzi o testy jednostkowe, ponieważ świetna dystrybucja wzorców pozwala przetestować wszystkie dostępne funkcje. Pod wieloma względami była to główna trudność, z jaką musieli się zmierzyć programiści z poprzednimi wzorcami oprogramowania MVC, MVP i MVVM.

Aby to wszystko ukoronować.

Wszystkie te 4 wzorce projektowe oprogramowania są często nazywane jednymi z najlepszych wzorców architektury dla rozwoju iOS, mimo że wszystkie z nich są mniej niż idealne i zdecydowanie nie są powszechnie stosowane w każdym projekcie, który rozwijasz. Po mrocznej stronie, oto krótka lista problemów, które ma każdy wzór:

• MVC, MVP, MVVM - wszystkie mają ten problem „ciasnego połączenia”, co sprawia, że ​​wprowadzanie aktualizacji do rozwoju, a następnie ich testowanie jest dość trudnym zadaniem do wykonania.

• VIPER vs MVVM, MVC lub MVP jest uważany za zwycięską sprawę; chociaż pomimo swojej dużej elastyczności i świetnej testowalności ma również wiele niuansów, które są trudne do wygenerowania.

Czy istnieje rozwiązanie w 100% stałe? Niezupełnie, ale dla każdego projektu jeden z tych 4 wzorców aplikacji na iOS może być właśnie tym, czego potrzebujesz. A jeśli nie, to byłaby mieszanina dwóch. A może nawet trzy. Mówi się, że fortuna sprzyja odważnym, więc dlaczego nie pobawisz się śmiało wzorcami projektowania oprogramowania?

Napisane przez Maxa Maszkowa i Elinę Bessarabovą.