Ist die UIViewController-Klasse im Sinne des MVC-Patterns eigentlich Teil der VIEW-Ebene oder Teil der CONTROLLER-Ebene ?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Macoun 2019 - Frühbucherrabatt bis 26.7.2019

  • Ist die UIViewController-Klasse im Sinne des MVC-Patterns eigentlich Teil der VIEW-Ebene oder Teil der CONTROLLER-Ebene ?

    Hallo Zusammen,

    eigentlich klingt das MVC-Pattern so einfach. Aber irgendwie habe ich immer das Gefühlt, dieses sehr grundsätzliche DesignMuster nicht richtig zu implementieren (nicht richtig zu verstehen) bei meinen Apps. ?(
    Deshalb bitte ich um Hilfe bei folgenden Fragen (bzgl. Implementierung des MVC-Patterns in iOS-Apps):

    - Ist die UIVIewControllerKlasse Teil der ControllerEbene oder Teil der ViewEbene im MVC-Pattern?
    - Was ist ein vernünftiger EntryPoint in die App?
    • die UIViewControllerKlasse (das entspräche der defaultEinstellung bei Nutzung des InterfaceBuilders), die dann die (Start)UIViewElemente und das (main)Model initialisiert (und besitzt) ODER
    • eine eigene customMain-Klasse, die dann wahrscheinlich in der AppDelegate initialisiert wird und ihrerseits einen StartViewController und weitere ModelKlassen instantiiert
    Vielen Dank für Antworten und Hinweise.
    :)
    Meine Signatur: Wir sehen die Welt nicht wie sie ist, sondern wie wir sind ! :huh:
  • Mac & i Test Abo
  • LukeSideWalker schrieb:

    - Ist die UIVIewControllerKlasse Teil der ControllerEbene oder Teil der ViewEbene im MVC-Pattern?
    Der gehört zur Controller-Schicht.

    LukeSideWalker schrieb:

    Was ist ein vernünftiger EntryPoint in die App?
    Für die gesamte App würde ich das App-Delegate verwenden. Ein Viewcontroller sollte möglichst unabhängig davon sein, ob er der erste ist.


    LukeSideWalker schrieb:

    eine eigene customMain-Klasse, die dann wahrscheinlich in der AppDelegate initialisiert wird und ihrerseits einen StartViewController und weitere ModelKlassen instantiiert
    Was soll das bringen? Wenn dir das App-Delegate zu voll laufen sollte, solltest du lieber gewisse Teilaufgaben in entsprechende Controller auslagern.
    „Meine Komplikation hatte eine Komplikation.“
  • Lieber macmoonshine,

    vielen Dank für Deine schnelle Antwort, echt nett, super !
    Ein paar kurze Kommentare und eine Frage zurück:


    macmoonshine schrieb:

    Der gehört zur Controller-Schicht.
    Das habe ich eigentlich auch immer so gesehen, aber damit bekommt der ViewController auch sehr viel "Ablauflogik" (schon über die segues, IBActions, ...) und da beginne ich immer zu "schwimmen", weil ich irgendwie denke, diese Ablauflogik ist Teil der BusinessLogik der App, sie sollte völlig unabhängig sein von einer konkreten Implementierung (und damit auch von UIKit). Müsste die CONTROLLER-Ebene nicht völlig unabhängig von der VIEW-Ebene sein? Ist der UIViewController nicht sehr nahe am Device?

    Dennoch danke, Deine Antwort bestärkt mich in meinen bisherigen Ansätzen.


    macmoonshine schrieb:

    Ein Viewcontroller sollte möglichst unabhängig davon sein, ob er der erste ist.
    Das ist einsichtig, danke, habe ich aber bis jetzt immer anders gemacht (ich habe also den START_ViewController im IB gebastelt und ihn als "initialVC" markiert). Um also die Standardprozedur (IB-Builder setzt Initial ViewController) ausser Kraft zu setzen, wirst Du wahrscheinlich in der AppDelegate in (didFinishLaunching....) so etwas einbauen, oder?

    Quellcode

    1. window?.rootViewController = IrgendEinStartViewController()
    Wenn man, nur mal angenommen, die UIViewControllerKlasse jedoch als Teil der ViewEbene ansieht (weil diese Klasse ja sehr stark mit der View und deren lifecycle (didLoad, didAppear, ...) gekoppelt ist), dann bräuchte man so einen UIKit unabhängigen, neutralen CONTROLLER (kein UIViewController) den man in der AppDelegate instantiiert und der selbst wieder einen ViewController (als ViewEbene) und das Model instantiiert, oder? Das war mit meiner zweiten Alternative oben gemeint.
    Meine Signatur: Wir sehen die Welt nicht wie sie ist, sondern wie wir sind ! :huh:
  • LukeSideWalker schrieb:

    Wenn man, nur mal angenommen, die UIViewControllerKlasse jedoch als Teil der ViewEbene ansieht (weil diese Klasse ja sehr stark mit der View und deren lifecycle (didLoad, didAppear, ...) gekoppelt ist), dann bräuchte man so einen UIKit unabhängigen, neutralen CONTROLLER (kein UIViewController) den man in der AppDelegate instantiiert und der selbst wieder einen ViewController (als ViewEbene) und das Model instantiiert, oder? Das war mit meiner zweiten Alternative oben gemeint.
    Views zeigen etwas an und / oder nehmen Nutzereingaben entgegen. Ein Viewcontroller verwaltet die Views aber nur. Er sagt zwar was die Views anzeigen sollen aber nicht wie. Views haben hingegen niemals eine starke Koppelung auf die Model-Ebene und kennen keine Business-Logik; z. B. weiß ein Button nur, dass er gedrückt wird – er weiß aber nicht, wie das verarbeitet wird.

    Ein Controller muss natürlich keine Views verwalten; siehe beispielsweise Managed-Object-Context in Core Data.
    „Meine Komplikation hatte eine Komplikation.“
  • Deine "Verwirrung" hat auf jeden Fall starke Gründe:
    In freier Wildbahn strapazieren viele ViewController die Definition von "Controller" ziemlich stark, und übernehmen nicht nur Aufgaben, die eher in die View-Ebene gehören, sondern oft auch solche aus dem Modell.
    Hier (UIKonf 2016 – Day 1– Steve "Scotty" Scott – MVVM-C In Practice - YouTube) zum Beispiel werden View und Controller beide in die Präsentationsschicht einsortiert.

    Ein anderer Vortrag, der wahrscheinlich in die selbe Richtung wie deine Ideen geht: slideslive.com/38897361/good-ios-application-architecture-en

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von t-no () aus folgendem Grund: Rechtschreibung

  • t-no schrieb:

    macmoonshine schrieb:

    Das ist dann aber kein MVC mehr, höchstens ein Erklärungsmodell für MVC.
    Eher ein Modell gegen MVC ;) - MVVM ist ja gewissermaßen ein "Konkurrenz-Pattern".
    Ok, kannte ich noch gar nicht. Wenn ich aber den ersten Satz im Wikipedia-Eintrag lese, bekomme ich schon graue Haare; äh noch mehr. ;)
    „Meine Komplikation hatte eine Komplikation.“
  • Danke für die Hinweise!

    t-no schrieb:


    Hier (UIKonf 2016 – Day 1– Steve "Scotty" Scott – MVVM-C In Practice - YouTube) zum Beispiel werden View und Controller beide in die Präsentationsschicht einsortiert.
    @t-no Dieser Vortrag von "Scotty" ist brilliant, toller Ansatz: youtube.com/watch?v=9VojuJpUuE8&app=desktop



    Vorerst werde ich jedoch beim CocoaStandard bleiben (MVC), aber wie man an diesem Vortrag erkennen kann, es gibt sehr gute Argumente, die UIViewControllerKlasse eher der VIEW/PRESENTATION - Ebene zuzuordnen.

    Werde das Thema als bearbeitet jetzt schließen. Noch einmal: DANKE für die ANTWORTEN.
    Meine Signatur: Wir sehen die Welt nicht wie sie ist, sondern wie wir sind ! :huh:
  • Meiner Meinung nach gehört der VC eindeutig zur Viewschicht, sagt ja der Name schon und Du hast ja selbst auch schon ein paar gute Argumente dafür gebracht: (viewDid... etc). Businesslogik würde ich in separate Objekte packen und diese dann im VC benutzen. Der VC sollte sich wirklich nur um die Verwaltung des Views kümmern. Hier noch ein Link zu einer pdf zu einem Cocoaheads-Vortrag:

    github.com/hydrixos/cocoaheads…b/master/2014/11/Talk.pdf
  • Markus Müller schrieb:

    Da das Ding trotzdem auch Controller im Namen hat, ist die Versuchung groß, da alles mögliche reinzuklatschen, Stichwort Massive View Controller.
    Das liegt dann aber nicht an Apple. Apple schreibt ja auch nirgendwo vor, dass die komplette Businesslogik in Viewcontrollern wohnen muss, und dass eigene Controller dafür sinnvoll sein können, ist auch unstrittig. Trotzdem gehören in MVC die Viewcontroller zur Controller- und nicht zur Viewschicht. ;)
    „Meine Komplikation hatte eine Komplikation.“
  • Da bin ich ganz bei Dir. Es gibt sogar ein sehr schönes WWDC Video von 2014 dazu, eine der seltenen Stellen, an denen Apple mal selbst was über Architektur erzählt:

    developer.apple.com/videos/play/wwdc2014/232/

    Um das noch etwas zu präzisieren: der VC ist ein Controller, der aber näher an der Viewschicht steht, als z.B. die Cocoa-NSObject/ArrayController oder der traditionelle MVC-Controller.
  • Ich finde auch, dass MVC eher ungeschickt ist als Bezeichner. MCCV wäre viel besser. Ich denke es macht einfach Sinn seine Buiseness Logik in einen eigenen unabhängigen Controller zu stekcen und dieses arbeitet mit dem Model. DArüber kommt dann erst der ViewController der sich aus dem Buiseness Controller holt was er braucht und es für den View aufbereitet.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Das lässt doch das Architekturmuster MVC völlig offen, wie du die Controller organisierst. Apple gibt die Viewcontroller als Entwurfsmuster vor. Das hindert aber niemanden daran, weitere Controller für die Modellebene oder zwischen anderen Controllern anzulegen. Es gibt ja auch von Apple bereits jede Menge Controller, die definitiv nichts mit der Viewebene zu tun haben.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Das lässt doch das Architekturmuster MVC völlig offen, wie du die Controller organisierst. Apple gibt die Viewcontroller als Entwurfsmuster vor. Das hindert aber niemanden daran, weitere Controller für die Modellebene oder zwischen anderen Controllern anzulegen. Es gibt ja auch von Apple bereits jede Menge Controller, die definitiv nichts mit der Viewebene zu tun haben.
    Sollte ja auch nicht gegen Apple gehen sondern eigentlich mehr gegen das MVC generell was ich in seiner Definition zu einfach finde. Alleine schon die Reihenfolge MVC ist ja falsch.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Sollte ja auch nicht gegen Apple gehen sondern eigentlich mehr gegen das MVC generell was ich in seiner Definition zu einfach finde.
    Hatte ich auch nicht so verstanden. MVC ist ja auch mit über 35 Jahren schon recht alt. In einer Zeit, wo die ersten grafischen Oberflächen entwickelt wurden, ist diese Erfindung schon extrem pfiffig. Die Einfachheit ist andererseits aber auch eine Stärke: Du kannst MVC in Programmen von HelloWorld bis zur Atomanlagensteuerung ohne großen Overhead einsetzen.

    Die grundlegende Idee ist aber auch heute immer noch sehr gut. Natürlich wird soetwas mit der zeit auch angepasst und erweitert. Letztendlich basiert ja MVVM auch auf den Ideen von MVC.

    Thallius schrieb:

    Alleine schon die Reihenfolge MVC ist ja falsch.
    Hatte ich auch dran gedacht. MCV oder VCM wären passender. ;)
    „Meine Komplikation hatte eine Komplikation.“