Desktop-Version

Start arrow Informatik arrow Strategie für die Portierung von Desktop-Business-Anwendungen auf iOS-gestützte Endgeräte

< Zurück   INHALT   Weiter >

3.6.2 Model-View-Controller

Apple setzt bei der Entwicklung von iOS-Apps auf das Model-View-ControllerArchitekturmuster (MVC-Muster).

Das MVC-Muster definiert drei Rollen, die Objekte in einer App innehaben können und beschreibt, welche Aufgaben diese übernehmen. Darüber hinaus legt es fest, wie die drei Objekte miteinander kommunizieren und was sie für Grenzen besitzen. Die drei Rollen heißen Model, View und Controller.

Abb. 3-11 Rollen und Kommunikationsrichtungen des MVC-Patterns162

Die Objekte der Rolle Model übernehmen die gleiche Aufgabe wie das Model des MVVM-Musters (siehe Kapitel Model-View-ViewModel3.6.1). Auch im MVCMuster existiert ein Mittler zwischen Model und View. Dieser Mittler heißt Controller.

Die View oder auch Ansicht genannt ist das Objekt, welches der Benutzer der App sehen kann. Es ist für die Darstellung der Steuerelemente und die Verarbeitung der Benutzereingaben verantwortlich. Mithilfe der Steuerelemente stellt die View die Daten des Objektmodells dar und erlaubt dem Anwender Änderungen vorzunehmen. Auch die View hat keinen direkten Kontakt zum Objektmodell, sie kommuniziert ausschließlich mit dem Controller.

Der Controller nimmt die Vermittlerrolle zwischen Model und View ein. Er reagiert auf Änderungen im Model und gibt sie an die View weiter und umgekehrt. Außerdem beinhaltet der Controller die gesamte Programmlogik der View und überwacht deren Lebenszyklus. Im Gegensatz zum ViewModel besitzt der Controller Referenzen auf die Interaktionselemente der Ansicht. Dadurch ist es nicht so einfach möglich, einer der beiden Komponenten auszutauschen.

Der Informationsfluss im MVC-Pattern ist relativ einfach. Sobald sich die Daten im Objektmodell ändern, informiert es den Controller darüber. Der Controller aktualisiert daraufhin die Anzeigeelemente der View. Ändert ein Anwender z.B. in einem Textfeld den Namen eines Bankkunden, so reagiert der Controller auf dieses Ereignis und speichert die neuen Daten im Model ab. Sind in beiden Fällen Datentypkonvertierungen oder Validierungen erforderlich, führt diese der Controller durch. Gegenüber dem MVVM-Muster müssen diese Aufgaben manuell implementiert werden.

3.6.3 Zusammenfassung der Gegenüberstelleng des MVC- und MVVMArchitekturmusters

Beide Architekturmuster verfolgen grundlegend den Ansatz, Geschäftslogik und Benutzerschnittstelle zu trennen. Dabei stellt das MVVM-Muster eine Weiterentwicklung des MVC-Musters da. Gleich ist offensichtlich die Rolle des Models. In beiden Architekturmustern ist dessen Existenz unabhängig jeglicher grafischen und technischen Implementierung. Zudem stellen beide Muster einen Mittler zum Datenaustausch zwischen Model und Ansicht bereit. Dessen Implementierung und Aufgabenverteilung macht jedoch im Wesentlichen den Unterschied beider Architekturmuster aus.

Aufgaben, die das MVC-Muster im Controller bündelt, teilt das MVVM-Muster auf verschiedene Instanzen auf, die teilweise durch das WPF-Framework automatisiert werden. So muss sich der Entwickler nicht mehr um die Aktualisierung der View oder des ViewModels kümmern. Diese Aufgabe übernimmt das Datenbindungssystem.

Außerdem ist die Spezialisierung des Objektmodells im ViewModel ausgelagert. Im MVC-Muster übernimmt dies ebenfalls der Controller.

Nicht von der Hand zu weisen ist, dass ein Entwickler bei der Implementierung des MVC-Musters mehr Aufwand betreiben muss, um den gleichen Erfolg wie beim MVVM-Muster zu erzielen. Ein Indiz dafür ist beispielsweise die automatische Eingabeüberprüfung und die Befehlsweiterleitung.

3.7 Untersuchungsergebnis

Kapitel 3 hat gezeigt, welche wesentlichen Unterschiede eine .NET-DesktopAnwendung mit WPF und eine iOS-App aufweisen. Ausschlaggebend für diese Unterschiede sind vor allem die physikalischen Gegebenheiten der Endgeräte (Windows PC vs. mobiles Endgerät) und die unterschiedlichen Benutzerkonzepte. Hinzu kommen die verschiedenen Entwicklungsplattformen und Laufzeitumgebungen. Außerdem spielen die technologischen Aspekte zur Erzeugung und Gestaltung der Oberfläche eine Rolle, sowie die Verknüpfung von Geschäftslogik und Präsentationslogik.

Trotz aller Unterschiede existiert mit MonoTouch eine Technologie, um für iOSgestützte Endgeräte Anwendungen zu entwickeln, ohne dabei Objective-C zu verwenden. Des Weiteren erlaubt MonoTouch die Portierung von .NET-Anwendungen auf iOS-Endgeräte über deren Quelltext. Die Portierfähigkeit ist aber mehr ein Nebenprodukt als das Hauptziel von MonoTouch.

Hieraus lassen sich im Wesentlichen folgende Herausforderungen für die Portierung der Desktop-Anwendung auf die iOS-Plattform ableiten.

1. Die grafische Benutzerschnittstelle muss neu gebaut werden, weil die Geräte und zur Verfügung stehenden UI-Frameworks inkompatibel sind

2. Die Komponenten der A-Software müssen mit MonoTouch kompiliert werden

3. MonoTouch inkompatible Bibliotheken sind gegen gleichwertige Lösungen zu ersetzen

 
Fehler gefunden? Bitte markieren Sie das Wort und drücken Sie die Umschalttaste + Eingabetaste  
< Zurück   INHALT   Weiter >

Related topics