2016-05-23 12 views
5

Ich lese viele Artikel über die saubere iOS-Architektur VIPER, ich verstehe die wichtigsten puropose: die Trennung von Bedenken.iOS VIPER: Wohin mit dem Formular Validierungscode?

Ich verwende es derzeit für mein Projekt. Ich habe Module, jeweils aufgeteilt nach Views, Interactors, Presenter, Entities und Routers (mit Storyboard).

Ich habe ein Modul: Adresse und ein Submodul Add für die Adresse hinzufügen Seite.

Also, ich habe meine Protokollansicht von meinem UIViewController implementiert. Der View-Controller enthält alle schwachen IBOutlet-Beschriftungen und Textfelder (für das neue Adressformular).

Das Adressformular enthält einige Felder wie:

  • Person Vorname und Nachname
  • Postleitzahl
  • Land
  • Zustand
  • Telefon
  • E-Mail
  • etc ..

In meinem Fall verwendet der Präsentator Benutzerinteraktionen nur auf den Interactor, der den API-Aufruf ausführt.

Aber vor dem Ausführen des API-Aufrufs möchte ich das Formular vorab validieren, um unnötige Netzwerkressourcen zu vermeiden.

muss ich zum Beispiel überprüfen:

  • den Inhalt von Land und sagen zu der Ansicht, dass Feld ist erforderlich, wenn leer ...
  • das Format der E-Mail und sagen Sie zu der Ansicht, dass Feld ungültig ...

Meine Frage ist, wo kann ich meinen Formularvalidierungscode eingeben?

Welche VIPER-Komponente sollte diesen Job ausfüllen?

Vielen Dank im Voraus!

Antwort

2

Da dies auf Business-Logik verbunden ist, würde ich sagen, dass die Validierung zu Interaktorsystem gehen sollte. Sie können sogar einen Worker erstellen, der als Form Interactor bezeichnet wird - wenn Ihre Validierung zu groß ist, aber interactor der richtige Ort dafür ist. Mit Delegierten können Sie den Benutzer benachrichtigen, wenn etwas nicht stimmt, was genau falsch ist, eine Fehlermeldung usw.

Ich würde auch auf http://clean-swift.com/clean-swift-ios-architecture/ beziehen.

+2

Kleine Randnotiz: Ich denke, der Autor der clean-swift.com Seite nicht vollständig die Grundidee von sauberem Code zu verstehen. Aus meiner Sicht ist es keine gute Idee, eine zirkuläre Abhängigkeit einzuführen (VC-> I-> P-> VC). Der View-Controller sollte dumm sein und nur seinen Presenter kennen. Also würde ich vorschlagen, es eher (VC-> P-> I) zu haben - mit Rückreferenzen, die als Delegierte implementiert werden. – orschaef

4

Einer der wichtigsten Vorteile von VIPER ist die Trennung von Bedenken, da die Informationen in dem entsprechenden Element eingekapselt ist.

Der Interactor befasst sich mit der „Business-Logik“, die (möglicherweise durch das Unternehmen erfolgen kann Teil dieser Validierung selbst) den größten Teil der Validierung Sorge umfasst. Die Ansicht wäre daher seine Daten an den Moderator, übergeben, die sie dem Interactor beziehen würde, die ihre Business Gültigkeit überprüfen würde und die Entity bitten sie um die Kohärenz der Daten zu informieren.

Die Verwendung von Bibliotheken zur Beschleunigung Ihrer Entwicklungen kann jedoch dazu führen, dass Sie die Einkapselung zur einfacheren Verwendung abwägen müssen. Zum Beispiel bietet SwiftValidator ziemlich umfangreiche Validierungsregeln, aber Sie müssen Ihre UITextField s an die Validator-Komponente übergeben.

Sie haben also die Wahl zwischen einer besseren gekapselten Architektur, die auf einem Interactor basiert (möglicherweise von einer Bibliothek wie Validators), oder einem MVVM-orientierten Tool wie .

1

Es scheint, dass Sie einen SOA architecture Ansatz für diesen Zweck verwenden sollten.

  1. Assembly

    Dort werden alle Code ist im Zusammenhang Vipernmodulkomponenten erstellen:

    Generell ist die saubere Architektur für App-VIPER-Modulen lassen sich in folgende Schichten unterteilt werden.

  2. Präsentation

    Sie es Komponenten wie Animator, LayoutPerformer, Moderator, Ansicht, Viewcontroller, Router halten sollte.

  3. Geschäftslogik

    Es ist für Interactor und Bündel von Dienstleistungen entwickelt wird. Im Idealfall ist jeder Dienst ein Zustand ohne Status und verwendet Klassen aus der Ebene "Core Components". Zum Beispiel kapselt der Dienst einige Netzwerk-Clients und -Anfragen ein und erzeugt einige Modelle als Ausgabe.

  4. Kernkomponenten

    Der Zweck dieser Schicht zu Ihrer Frage verbunden ist. Hier ist ein Platz für Dinge wie Response Validator, Object Mapper, Netzwerk-Client, etc. Also die Antwort ist setzen Sie es in Core-Komponente Ebene.

  5. Modell Schicht

    Es ist die tiefste Schicht, die alle Entitäten halten soll.

Ok, es klingt gut, aber wie kann ich das Projekt in diesem Fall strukturieren?

Sie können zum Beispiel die Struktur unten verwenden.

--Modules 
 
----Module 
 
------Interactor 
 
------Presenter 
 
------Assembly 
 
------Router 
 
------View 
 
--Services 
 
--Core 
 
----Validators 
 
----Mappers 
 
--Models