Frage In MVC, wo verweisen Sie auf Ihre Modellklassen?


Ich frage mich seit einiger Zeit, nachdem ich verschiedene Leute gefragt habe und ohne dass jemand von ihnen eine "zumindest ein bisschen konkrete Antwort" nennt:

Frage:

In einer iPhone-Anwendung sollte eine Anwendung die Verweise auf ihre Modellklassen behalten (unter Verwendung der MVC Ansatz) ?

In iPhone (und Cocoa) Anwendungen haben wir das, was wir "App Delegate" nennen, was im Grunde unsere Anwendung startet und in unseren Controllern auch UITouch Ereignisse behandelt.

Also ist der App Delegate ein Controller? eine Modellklasse? keiner der beiden? Ich denke nicht zu wissen, dass es auch verwirrend ist, zu wissen, wo man die Model References platzieren kann.

Beispiel:

Sie haben den Anwendungsdelegaten, dieser Delegat enthält einen Verweis auf den View-Controller Ihrer Anwendung. Wenn meine Anwendung Modellklasse A (eine Webserver-Daemon-Klasse) und eine Klasse B verwenden würde, die von diesem Webserver abgefragte Daten speichert.

Wo würdest du die Referenzen zu A und B speichern? (App Delegate? Controller anzeigen? Beide?)

Es gibt viele Möglichkeiten hier, aber als Beispiel würde ich gerne wissen, wie würdest du mvc verwenden, um diese Anwendung zusammenzustellen, die nur eine Ansicht verwendet.


15
2018-02-08 14:17


Ursprung


Antworten:


Es ist verlockend, alles in das AppDelegate zu legen, aber wenn Sie damit beginnen, wird Ihr AppDelegate voller Referenz-Hacks sein. Wenn du eine strikte MVC machst, solltest du 3 Dinge haben:

  • Ein Model
  • Ein View-Controller (nur für View-Logik)
  • Ein Controller (Für die Koordination zwischen der Ansicht und dem Modell)

So habe ich zum Beispiel ein Model Foo und einen Foo Controller. Ich hätte:

  • Foo.m (Modell)
  • FooViewController.m (Zeigt ein Foo an)
  • FooController.m (Steuert die Logik)

Und schließlich, um deine Frage zu beantworten, würde ich meine Referenzen zu Foo's im foo Controller speichern. Ich benutze gerne Singles für meine Controller, aber das bin nur ich. Wenn Sie ein Singleton verwenden, können Sie einfach Folgendes tun: [[FooController sharedInstance] listOfFoos] um deine Foo's zu bekommen


7
2018-02-08 14:27



In meinen Anwendungen benenne ich normalerweise die AppDelegate-Klasse in AppController um, wenn das hilft, Dinge besser konzeptionell zu erklären. Ihr App-Controller ist verantwortlich für das Erstellen und / oder Konfigurieren des Modell-Controllers (der Ihre Sammlung von Modellobjekten verwaltet) und Fenster- oder Ansichts-Controllern, Einrichten von Referenzen zwischen diesen, und Aufrufen von Methoden auf diesen Controllern als Reaktion auf NSApplication-Delegate-Methoden oder High-Level-Action-Methoden aus dem Hauptmenü. Abhängig davon, wie komplex Ihre Anwendung ist, verfügen Sie möglicherweise auch über zusätzliche Modell- oder Ansichtscontroller, die außerhalb Ihres App-Controllers erstellt werden.

Natürlich, wenn Sie eine einfache Anwendung haben, gibt es keinen wirklichen Grund, Ihren App-Controller nicht die Rolle des Modell-Controllers zu spielen, wenn Sie möchten. Was Sie vermeiden wollen, ist eine Datei mit Hunderten von Codezeilen, die alle konzeptionell nicht miteinander in Beziehung stehen.


3
2018-02-08 18:16



Traditionell erstellt der Controller das Modellund initialisiert dann die Ansicht mit diesem Modell. Der Controller hört dann Änderungen im Modell ab und zeigt und koordiniert den Programmablauf. Das wäre meine allgemeine Antwort, vielleicht wären die Dinge in der Praxis für die iPhone-Entwicklung anders.


1
2018-02-08 14:27



Wo sollte eine Anwendung in einer iPhone-Anwendung die Verweise auf ihre Modellklassen behalten (mit dem MVC-Ansatz)?

Die Controller-Schicht behält Referenzen auf die Modellschicht bei.

Also ist der App Delegate ein Controller? eine Modellklasse? keiner der beiden?

Der App-Delegierte ist ein Controller.

Wo würdest du die Referenzen zu A und B speichern?

A und B sind Modellklassen, die normalerweise von der Controller-Ebene erstellt und verwaltet werden.

Ich würde wirklich gerne wissen, wie würdest du mvc verwenden, um diese Anwendung zusammenzustellen, die nur eine Ansicht verwendet.

Der Zweck der Controller-Schicht besteht darin, den Modell- und Ansichtsschichten die Möglichkeit zu geben, eigenständig zu sein. Das Modell sollte nichts über die Controller- oder Ansichtsebenen wissen. Die Ansicht sollte nichts über die Controller- oder Model-Layer wissen. Die Aufgabe des Controllers besteht darin, auf der einen Seite einen doppelseitigen Adapter zum Modell und auf der anderen Seite die Ansicht zu bilden.

Ich würde Ihre Beispiel-App wie folgt einrichten:

  • UIApplication delegiert an AppDelegate.
  • Wenn der Betrieb Ihrer Serverklasse (A) ist einfach:
    • AppDelegate erstellt und besitzt Instanzen der Serverklasse A.
  • Wenn der Betrieb Ihrer Serverklasse (A) ist kompliziert:
    • Erstellen Sie eine dedizierte Controller-Klasse (C), um den Server zu steuern.
    • AppDelegate erstellt und besitzt Instanz (en) der Klasse C. Eine Instanz von (C) für jede Instanz von (A).
    • Jede Instanz der Klasse C erstellt und besitzt eine Instanz der Klasse A.
  • AppDelegate erstellt und besitzt eine Instanz Ihrer ViewController-Klasse, die Ihre Ansicht lädt und besitzt.

Es ist nicht klar in der Frage, was der Zweck der Klasse B ist.

  • Wenn es sich um einen Datenblock handelt, der nur für die Verwendung von A bestimmt ist (wie Konfigurationsdaten oder statische Websitedaten), würde ich ihn erstellen und dem Server zuweisen (A).
  • Wenn es sich um Daten handelt, die während des Serverbetriebs erstellt werden und in der Ansicht angezeigt werden müssen, benötigen Sie wahrscheinlich Folgendes:
    • Ein veränderbares Array im Besitz von A, um Instanzen von B zu halten.
    • Eine weitere Controller-Klasse (D), die auf dieses Array verweist und als Datenquelle / Delegat für Ihre Ansicht fungiert.

1
2018-02-08 18:04



Ich finde, dass AppDelegate in den meisten Fällen eine gute Möglichkeit bietet, einige Basisfunktionen zu platzieren (z. B. ein Hintergrundbild, das in jedem Controller angewendet werden soll), aber dass Sie an anderer Stelle zusätzliche Controller und Modellcode benötigen. Ein navController oder rootController würde oft als eine Eigenschaft auf Ihrem AppDelegate platziert werden.

Also, ich würde sagen, das ist irgendwo zwischen "weder" und "Controller", sondern eher in Richtung "weder". Definitiv kein "Model"!


0
2018-02-09 02:27