Viele Ansichten haben Teilansichten, die nicht notwendigerweise mit einem eigenen Controller verknüpft sein müssen. In Apples eigenen Tutorial zum Erstellen von benutzerdefinierten Ansichten sind sie eigentlich nicht Erstellen Sie für jede Unteransicht einen Unter-UIViewController.
Allerdings stoße ich oft in Situationen, in denen ich eine Ansichtshierarchie habe, in der eine Unteransicht einer Unteransicht eine Schaltfläche enthält, die eine Netzwerkanforderung sendet. In diesem Fall könnte ich ein Ziel machen:
%Vor%Und dann könnte ich in derselben myView-Klasse mit dieser Netzwerkanforderung umgehen, aber das scheint das MVC-Muster zu brechen. Views sollten keine Logik machen, sie sollten nur Zeug anzeigen, richtig?
Eine andere Option, die wir machen können, ist, dass jede Ansicht Zugriff auf ihren übergeordneten oder übergeordneten Controller hat, den sie für die Logik benötigt. In dem Fall könnte mein Ziel etwa so aussehen:
%Vor%Aber das scheint auch keine richtige Lösung zu sein. Wieder scheint es, als würden wir nur die MVC durchbrechen und verweben.
Stattdessen haben wir, soweit ich es gesehen habe, noch eine von zwei Optionen:
Erstens könnten wir Ziele und die gesamte Logik vom übergeordneten Controller selbst hinzufügen. Aber das macht uns böse Ketten wie folgt:
%Vor%Diese lange Liste von Zugängen gibt mir die Schüttelfrost und sieht einfach schlecht aus. Aber es scheint immer noch der MVC zu folgen. Technisch machen wir die Logik im Controller, oder?
Aber es könnte eine andere Option geben. Wir könnten jeder Ansicht einen Controller geben und jeder UIViewController hätte für jede neue Subview einen Sub-Controller.
Aber einige Ansichten sind statisch. Sie haben keine Logik, also brauchen sie nicht unbedingt einen Controller. Aber im Grunde brauchen wir für jede Ansicht einen, wenn wir diese Konvention befolgen, andernfalls haben wir Unstimmigkeiten, wo ein Controller einen Enkel-Controller, aber keinen Kind-Controller hat.
Wir müssen also eine Menge leerer Schatullen für unsere Controller erstellen. Dies baut eine Menge toten Code auf, der nie benutzt wird, was ein bisschen Software-Fehler verursachen kann.
Also jemand, der klüger und klüger ist als ich , was ist die richtige Lösung hier?
Es gibt wahrscheinlich MVC-Gurus, die klüger sind als ich, aber ich werde es einen Spalt lang geben:
Wenn Sie Netzwerkanforderungen in einer UIView-Unterklasse bearbeiten, brechen Sie definitiv das MVC-Muster. Laut Apples MVC-Referenz:
Ein Ansichtsobjekt ist ein Objekt in einer Anwendung, das Benutzer sehen können. Ein Ansichtsobjekt kann sich selbst zeichnen und auf Benutzeraktionen reagieren.
Wie es aussieht, soll eine Ansicht einfach damit umgehen, was Benutzer sehen und mit denen sie interagieren können. Gehe nicht auf diese Route.
Gehen wir zurück zu Apples MVC-Referenz für View-Controller:
Ein Controller-Objekt fungiert als Vermittler zwischen einem oder mehreren View-Objekten einer Anwendung und einem oder mehreren seiner Modellobjekte. Steuerungsobjekte sind somit eine Leitung, durch die Objekte Objekte über Änderungen von Modellobjekten und umgekehrt erfahren. Controller-Objekte können auch Setup- und Koordinierungsaufgaben für eine Anwendung ausführen und die Lebenszyklen anderer Objekte verwalten.
Beachten Sie, wie das Dokument "ein oder mehrere" aussagt, da es für einen View-Controller völlig akzeptabel ist, die Logistik mehrerer Ansichten zu verwalten. Persönlich würde ich sagen, dass, wenn Ihre Ansicht nur eine Schaltfläche hat, die einen Delegaten für Netzwerkanforderungen benötigt, gehen Sie voran und legen Sie den View-Controller der übergeordneten Ansicht als Delegat fest.
Sie sollten eine Ansicht über einen eigenen Ansichts-Controller verfügen lassen, sobald die Datenverarbeitung einer Ansicht "komplex" wird. Aus Gründen der Kürze definiere ich dies als "mehrere Aktionen, die den sichtbaren Zweck des View-Controllers der übergeordneten Ansicht verdecken würden." p>
Davon abgesehen, ist es möglich, in einem View-Controller mit #pragma mark genau zu markieren, warum der Code dort ist, wo er ist, also verwenden Sie Ihr Urteil hier.
Es ist definitiv machbar, jedem View seinen eigenen View-Controller zu geben, aber glauben Sie wirklich, dass es notwendig ist? Das Erstellen eines ganz neuen View-Controllers bei jedem Tippen auf einen einzelnen Button ist bei einer expansiven App sicherlich ein Overkill.
Gehen Sie mit Option # 2 und verwenden Sie Ihr bestes Urteil. Sie können nicht bestraft werden, wenn Sie das MVC-Muster brechen. Am schlimmsten ist, dass Sie Ihren Code in einen neuen View-Controller umgestalten, wenn die Logik Ihrer Ansicht komplex wird.
Model-View-Controller - iOS-Entwicklerbibliothek
Hoffe, das hilft!
Zunächst sehr gut gestellte Frage!
Um Ihre Frage zu beantworten - Nein, es ist nicht notwendig, dass jeder UIView über einen View-Controller verfügt, um sie zu verwalten, aber es ist branchenüblich, das UIView -Management selbst auszulagern - das MVC-Entwurfsmuster.
Ich würde empfehlen, Delegierte zu verwenden. Es funktioniert gut, MVC-Muster intakt zu halten und benutzerdefinierte UIView wiederverwendbar zu machen.
Ich habe viele benutzerdefinierte UIViews, die ich für mehrere View-Controller verwende. Die Art, wie ich mit ihnen umgehe, ist:
UIView und übergebe die Behandlung an wen auch immer der Delegierte. Beginnen wir mit den Grundlagen ... Ansichten sollten dumm sein.
Wenn Sie jemals eine Ansicht schreiben, die Anwendungslogik, Geschäftslogik oder ein Modellobjekt referenziert, dann machen Sie es falsch.
HINWEIS: Dazu gehören Tabellenansichtszellen und Auflistungsansichtszellen !!
Sie haben die richtige Antwort auf das Problem.
Erstens könnten wir Ziele und die gesamte Logik vom übergeordneten Controller selbst hinzufügen.
Aber Sie haben ein Problem.
Aber das macht uns böse Ketten
Praktisch sollte dies kein Problem sein. Halten Sie Ihre benutzerdefinierten Ansichten flach. Sie sollten immer in der Lage sein, maximal 1 Ebene der Ansichtsindirektion beizubehalten (mit Ansichtseigenschaften, die eine zweite Ebene der Indirektion darstellen).
%Vor%Um dies zu erreichen, versuche ich einige Grundregeln zu befolgen.
Tags und Links ios uiview uiviewcontroller