Articles

Co to jest VIPER?

To jest pierwszy post z serii postów o architekturze projektu iOS. W tych postach nie zamierzam wchodzić w szczegóły dotyczące plusów i minusów wzorców architektonicznych, zamiast tego skupię się na zarysowaniu różnych struktur architektonicznych, które mogą być zastosowane w projekcie iOS. Mam jednak zamiar napisać bardziej opiniotwórczy artykuł jako podsumowanie / Podsumowanie dla różnych pojęć wprowadzonych w tej serii później.

w tym poście przedstawię wzór architektoniczny Vipera. VIPER może być używany jako wzór projektowy na różnych platformach, w tym poście, będę skupiać się na użyciu VIPER w projekcie iOS.

VIPER oznacza różne elementy wzorca architektonicznego; Widok, Interaktor, prezenter, Entity i Routing. Podstawową zasadą VIPER jest rozdzielenie funkcjonalności aplikacji na te różne komponenty, w celu osiągnięcia niskiego sprzężenia między różnymi komponentami aplikacji i przestrzegania zasady jednolitej odpowiedzialności.

oprócz komponentów zawartych w VIPER, które są wymienione powyżej, wzorzec VIPER wykorzystuje również helpery, które zarządzają logiką między zewnętrznymi źródłami, takimi jak baza danych, a aplikacją iOS, komponenty te mogą być określane jako Menedżery sieci.

różne komponenty Vipera

na początek przejrzę różne komponenty Vipera i ich obowiązki. Opisując różne komponenty Vipera, podam przykłady, gdzie znaleźć różne komponenty w tradycyjnie skonfigurowanym projekcie MVC iOS (w stosownych przypadkach).

Po wprowadzeniu komponentów skupię się na tym, jak różne komponenty łączą się w projekcie i jak komponenty odnoszą się do siebie.

Widok

widok jest odpowiedzialny za wyświetlenie informacji użytkownikowi aplikacji. Ponieważ widok jest tym, co widzi użytkownik, jest to ważny komponent, który zapewnia użytkownikowi bezpośredni interfejs do aplikacji – w tradycyjnym projekcie iOS może to być widok w scenorysie lub w .plik xib. Widok jest zatem również odpowiedzialny za zapewnienie aplikacji sposobu na wprowadzanie informacji przez użytkownika.

Interactor

interactor zawiera logikę biznesową aplikacji dotyczącą obsługi danych. Interaktor nie jest bezpośrednio odpowiedzialny za Pobieranie danych z serwera, często są one przydzielane do jednego lub kilku menedżerów sieci. Jednak interactor jest odpowiedzialny za interakcję z tymi menedżerami sieci. Ponieważ określona aplikacja może wymagać pobierania danych z wielu różnych źródeł danych, interaktor może inicjować żądania sieciowe za pośrednictwem wielu różnych menedżerów sieci. Interaktor musi pobrać dane wymagane dla konkretnego przypadku użycia aplikacji, z różnych punktów danych, zgodnie z logiką biznesową aplikacji. Po pobraniu danych ze wszystkich zewnętrznych serwerów za pośrednictwem menedżerów sieci interaktor obsługuje wszelkie niezbędne manipulacje danymi.

Uwaga: Jeśli znasz nowoczesną architekturę MVVM, odpowiedzialność interaktora może być porównana z odpowiedzialnością Viewmodelu MVVM.

prezenter

obowiązkiem prezentera jest stosowanie logiki sposobu wyświetlania treści. Prezenter wykorzystuje dane dostarczone przez interakcję, a następnie stosuje niezbędną logikę sposobu prezentacji tych danych w widoku. Prezenter jest również odpowiedzialny za logikę, w jaki sposób aplikacja powinna reagować na dane wejściowe i interakcje z użytkownikami. Odpowiedzialność ta jest często przypisywana Viewcontrollerowi w kontekście projektu iOS.

Entity

entity to model przechowywania danych. Może to być trwały model pamięci masowej – taki jak podstawowy obiekt danych-lub może to być bardziej tymczasowy model pamięci masowej-taki jak struktura, klasa lub Enum. Encja nie powinna zawierać żadnej logiki związanej z formatowaniem danych przed ich wyświetlaniem, nie powinna też zawierać logiki o sposobie pobierania danych (np. żądanie sieciowe). Encja zawiera po prostu zmienne, które są specyficzne dla modelu, który reprezentuje. Odpowiedzialność za sposób wyświetlania danych podmiotu spoczywa na prezenterze, a menedżer sieci jest odpowiedzialny za sposób pobierania danych.

Routing

w końcu komponent routing jest odpowiedzialny za logikę wymaganą do i nawigację między różnymi widokami aplikacji. Ten komponent opisuje, co jest wymagane do wyświetlenia każdego z widoków aplikacji. Po dostarczeniu/utworzeniu wszystkich zależności wymaganych dla określonego widoku, routing inicjalizuje widok, dostarczając te zależności (nazywa się to wstrzykiwaniem zależności), a następnie prezentuje widok.

Uwaga: komponent routing bierze odpowiedzialność za poruszanie się między różnymi widokami, jest to odpowiedzialność, która jest tradycyjnie podzielona między segue storyboard i ViewController (w funkcji preparedforsegue). Aplikacja korzystająca z architektury VIPER zwykle nie zawiera żadnych segmentów między różnymi widokami storyboardu.

zgodnie z architekturą Vipera żadna klasa inna niż menedżer danych nie powinna mieć świadomości podstawowych danych lub podstawowych obiektów danych. Zamiast tego Klasa Menedżera danych konwertuje podstawowy obiekt danych na PONSO (zwykły stary NSObject) przed przekazaniem go do innej klasy, takiej jak Klasa interaktora.

za pomocą modułów z VIPEREM

do modułu można dodać ekran lub zestaw ekranów. Moduł może być po prostu folderem w projekcie, który zawiera funkcjonalność wymaganą dla określonego ekranu. Wzór modułu może być przydatny do wymiany lub ponownego użycia określonego zachowania dla różnych platform. Na przykład, jeśli określona funkcjonalność istnieje tylko dla aplikacji na iPada, można ją łatwo zastąpić innym modułem dla aplikacji na iPhone ’ a.

Jak będzie wyglądała ta struktura w projekcie iOS?

do tej pory w tym artykule zidentyfikowałem różne komponenty Vipera, a także różne obowiązki tych komponentów. Przyjrzyjmy się dokładniej, jak te komponenty ze sobą współdziałają i jak pasują do siebie w projekcie.

fakt, że każdy z komponentów w modelu VIPER jest dedykowany do określonego zadania, ułatwia nam łączenie komponentów w celu spełnienia zadania wymaganego do działania aplikacji, a także ponowne wykorzystanie komponentów w różnych częściach aplikacji. Jak pokazuje powyższy diagram, różne komponenty współdziałają ze sobą, aby osiągnąć określony cel.

podczas gdy Widok zapewnia użytkownikowi określony ekran aplikacji, prezenter odgrywa ważną rolę w podejmowaniu decyzji o tym, jak dane powinny być wyświetlane w widoku i co zrobić z danymi wprowadzanymi przez użytkownika do widoku. Prezenter pobiera dane, które powinny być wyświetlane w określonym widoku z interaktywnego i formatuje dane, zanim zostaną wyświetlone w widoku. Kiedy użytkownik naszej aplikacji wchodzi w interakcję z widokiem, obowiązkiem prezentera jest podjęcie decyzji o zmianie widoku, aby zapewnić użytkownikowi niezbędną informację zwrotną.

Jeśli dane wejściowe użytkownika powinny być przechowywane do późniejszego pobrania, prezenter przekazuje dane do interaktora. Interaktor decyduje o tym, w jaki sposób dane powinny być formatowane, stosując odpowiednią logikę biznesową, przed przekazaniem ich menedżerowi sieci (do zewnętrznego przechowywania informacji) lub jednostce.

aplikacja często zawiera wiele ekranów, o różnych funkcjach, dedykowanych do spełnienia określonego przypadku użycia. Każdy z tych ekranów (lub zestaw powiązanych ekranów) składa się z widoku, Interaktora, prezentera, jednostki i komponentu routingu, które łącznie mogą być określane jako moduł. Ponieważ niektóre ekrany mogą wymagać tych samych elementów lub tego samego interaktora co inny ekran, komponent VIPER może być ponownie użyty w różnych modułach.

Routing może istnieć na różnych poziomach w aplikacji. Może istnieć router specyficzny dla modułu, zapewniający nawigację między zbiorem ekranów. Router może również istnieć na wyższym, bardziej nadrzędnym poziomie aplikacji, zapewniając funkcjonalność nawigacyjną między aplikacjami wyższego poziomu, głównymi widokami (na przykład tworzenie widoków i przekierowywanie do tych widoków z paska kart).

Przydatne linki:

  • objc.io
  • wzorce architektury iOS – Bohdan Orłow
  • budowanie aplikacji iOS z architekturą VIPER-Amit Shekhar

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.