iOS VIPER Architektur, wer muss ein ganzes Modul instanziieren?

8

Berücksichtigung der VIPER-Struktur

Ich habe zwei Module, A und B. Das erste Modul A möchte über den Presenter eine Aktion ausführen, die im Modul B ausgeführt werden muss, also teilt es seinem Drahtgitter mit, dies zu tun. Die Frage ist, wer für die Instanziierung des gesamten Moduls verantwortlich ist (View, Interactor, Presenter ...). Ich sah einige Beispiele mit unterschiedlichen Ansätzen:

  • Erstellen Sie alle Module am Anfang der App.
  • Erstellen Sie das gesamte Modul im Drahtmodell des Moduls. In diesem Fall instanziiert eine Klassenmethode von BWireframe das gesamte B-Modul.

Berücksichtigt man, dass das Drahtgitter für das Routing verantwortlich ist, ist es auch verantwortlich für die Erstellung seines Moduls?

    
emenegro 12.12.2014, 10:55
quelle

3 Antworten

15

TL; DR : Ich würde dir empfehlen, ein DI-Framework wie Typhoon zu verwenden und das zuzulassen Instanziierung handhaben.

Der Grund, warum Sie wahrscheinlich nicht möchten, dass Ihre Wireframes alles in einem VIPER-Modul (View, Presenter, Interactor, DataManager) instanziieren, ist, dass Sie Abhängigkeiten direkt für jede dieser Komponenten erstellen werden.

Abhängigkeiten machen Software resistent gegen Veränderungen: wenn wir daran mit unserer Zwiebelarchitektur denken / sechseckige Architektur Hüte auf, würde der Drahtmodell die Grenzen von mindestens zwei separaten Schichten Ihrer Zwiebel überschreiten, indem Sie nicht nur wissen die Ansicht, aber der Datenmanager.

Dies zwingt uns, Wireframes als eine allgemeine Infrastrukturklasse zu behandeln: d. h. etwas auf der äußersten Ebene Ihrer Anwendung.

Dies widerspricht jedoch der anderen (und eher realen) Verantwortung des Drahtmodells: der Navigation. Während dies immer noch die Infrastrukturschicht ist, gehört sie fest und spezifisch in UIKit ( -presentViewController: etc.).

Also IMHO, VIPER Drahtmodell macht zu viel.

Das einzig Vernünftige ist, die zwei Verantwortlichkeiten aufzuteilen:

  1. Initialisierung der VIPER-Klassen: Sie können eine Factory einführen oder DI-Tools verwenden, die dieses Problem lösen sollen
  2. Navigation machen: Dies bleibt im Rahmen eines Wireframe .

Zusätzliche Hinweise

Wenn Sie sich fragen " wer das nächste Modul instanziiert?", dann nochmal, IMHO, ich denke es ist nicht richtig, dass einige Drahtgitter von Module A mit Drahtgitter von Module B sprechen trotz was der VIPER Beitrag sagt.

Der Grund ist, dass Module A jetzt von Module B abhängig gemacht wird, was zu einer engen Kopplung führt: Dies vereitelt den Zweck von Modulen. Viel mehr Diskussion zu diesem Thema im VIPER-TODO-Projekt bei GitHub =]

Hoffe, das hilft.

    
fatuhoku 02.02.2015, 13:39
quelle
1

Ich denke, dass das Eingangstor zu einem Modul das Drahtgitter ist, also stimme ich Ihrem zweiten Ansatz zu.

Das Erstellen eines Moduls beinhaltet die Erstellung aller seiner Objekte und es scheint mir eine Art Verschwendung.

    
Asaf Shveki 20.01.2015 08:44
quelle
1
___ qstnhdr ___ iOS VIPER Architektur, wer muss ein ganzes Modul instanziieren? ___ qstntxt ___

Berücksichtigung der VIPER-Struktur

Ich habe zwei Module, A und B. Das erste Modul A möchte über den Presenter eine Aktion ausführen, die im Modul B ausgeführt werden muss, also teilt es seinem Drahtgitter mit, dies zu tun. Die Frage ist, wer für die Instanziierung des gesamten Moduls verantwortlich ist (View, Interactor, Presenter ...). Ich sah einige Beispiele mit unterschiedlichen Ansätzen:

  • Erstellen Sie alle Module am Anfang der App.
  • Erstellen Sie das gesamte Modul im Drahtmodell des Moduls. In diesem Fall instanziiert eine Klassenmethode von BWireframe das gesamte B-Modul.

Berücksichtigt man, dass das Drahtgitter für das Routing verantwortlich ist, ist es auch verantwortlich für die Erstellung seines Moduls?

    
___ answer28040937 ___

Ich denke, dass das Eingangstor zu einem Modul das Drahtgitter ist, also stimme ich Ihrem zweiten Ansatz zu.

Das Erstellen eines Moduls beinhaltet die Erstellung aller seiner Objekte und es scheint mir eine Art Verschwendung.

    
___ antwort43335658 ___

  • Verwenden Sie dieses Xcode-Plugin ( Ссылка ), um VIPER-Dateien automatisch zu erstellen und zu initiieren.

  • Lesen Sie diesen Beitrag, um ausführlichere Tipps zur VIPER-Instanziierung (und Erklärung des obigen Plugins) zu erhalten: Ссылка

Wenn Sie den Modul-Initialisierungscode auf einem eigenen Router verwenden, wird eine Reihe von Codewiederholungen eliminiert, besonders bei großen Projekten. Sie müssen diese Erweiterungen einmal erstellen:

%Vor%

Und dann lassen Sie den Initialisierungscode auf dem Router jedes VIPER-Moduls:

%Vor%

Es mag nach vielen Schritten aussehen, aber gute Neuigkeiten: Das oben erwähnte Plugin automatisiert das auch!

    
___ answer28279056 ___

TL; DR : Ich würde dir empfehlen, ein DI-Framework wie Typhoon zu verwenden und das zuzulassen Instanziierung handhaben.

Der Grund, warum Sie wahrscheinlich nicht möchten, dass Ihre Wireframes alles in einem VIPER-Modul (View, Presenter, Interactor, DataManager) instanziieren, ist, dass Sie Abhängigkeiten direkt für jede dieser Komponenten erstellen werden.

Abhängigkeiten machen Software resistent gegen Veränderungen: wenn wir daran mit unserer Zwiebelarchitektur denken / sechseckige Architektur Hüte auf, würde der Drahtmodell die Grenzen von mindestens zwei separaten Schichten Ihrer Zwiebel überschreiten, indem Sie nicht nur wissen die Ansicht, aber der Datenmanager.

Dies zwingt uns, Wireframes als eine allgemeine Infrastrukturklasse zu behandeln: d. h. etwas auf der äußersten Ebene Ihrer Anwendung.

Dies widerspricht jedoch der anderen (und eher realen) Verantwortung des Drahtmodells: der Navigation. Während dies immer noch die Infrastrukturschicht ist, gehört sie fest und spezifisch in %code% ( %code% etc.).

Also IMHO, VIPER Drahtmodell macht zu viel.

Das einzig Vernünftige ist, die zwei Verantwortlichkeiten aufzuteilen:

  1. Initialisierung der VIPER-Klassen: Sie können eine Factory einführen oder DI-Tools verwenden, die dieses Problem lösen sollen
  2. Navigation machen: Dies bleibt im Rahmen eines %code% .

Zusätzliche Hinweise

Wenn Sie sich fragen " wer das nächste Modul instanziiert?", dann nochmal, IMHO, ich denke es ist nicht richtig, dass einige Drahtgitter von %code% mit Drahtgitter von %code% sprechen trotz was der VIPER Beitrag sagt.

Der Grund ist, dass %code% jetzt von %code% abhängig gemacht wird, was zu einer engen Kopplung führt: Dies vereitelt den Zweck von Modulen. Viel mehr Diskussion zu diesem Thema im VIPER-TODO-Projekt bei GitHub =]

Hoffe, das hilft.

    
___ tag123ios ___ iOS ist das mobile Betriebssystem, das auf dem Apple iPhone, iPod touch und iPad ausgeführt wird. Verwenden Sie dieses Tag [ios] für Fragen zur Programmierung auf der iOS-Plattform. Verwenden Sie die verwandten Tags [objective-c] und [swift] für Probleme, die für diese Programmiersprachen spezifisch sind. ___ tag123architecture ___ Architektur umfasst den Prozess, die Artefakte und die High-Level-Struktur einer Lösung. ___
Marcelo Gracietti 11.04.2017 02:12
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Warum kann PyImport_Import ein Modul nicht aus dem aktuellen Verzeichnis laden?