Drucken
Viele Softwareanwender wollen ihre Software sowohl im Büro, als auch zu Hause und unterwegs nutzen. Dabei soll von den Eingabemöglichkeiten der jeweiligen Geräte Gebrauch gemacht werden können. Zusätzlich sollen sich die Anwendungen so nativ wie möglich auf jedem Gerät verhalten und aussehen.
Das Zeitalter der installierten Anwendungen und mobilen "Apps" ist sicherlich bald vorbei. In vielen Bereichen wandert die Software ins Web. Auch auf Mobilgeräten werden die Browser immer leistungsfähiger und "Web-App-tauglicher". Leider macht das die Welt der Anwendungsentwickler nur wenig einfacher. Es herrscht immernoch eine große Fragmentierung an Geräteplattformen, die beherrscht werden muss. Außerdem unterscheiden sich mobile Web-Anwendungen enorm von "vollwertigen" Webanwendungen.
Die gerätespezifische Optik lässt sich meist mit CSS und JavaScript-Frameworks realisieren. Allerdings verlangt der große Unterschied zwischen Laptop/Desktop-PC und Mobiltelefon eine derartige Anpassung, wie sie mit CSS meist nicht realisierbar ist. Selbst wenn die Anpassung mit CSS möglich ist, werden auch die auf Mobilgeräten nicht angezeigten Elemente übertragen, was die Dateigröße unnötig aufbläht. Die Nutzung von CSS-Media-Queries verlangt außerdem eine recht grobe Verbiegung des Designs und moderne Browser auf den mobilen Endgeräten.
Das Zeitalter der installierten Anwendungen und mobilen "Apps" ist sicherlich bald vorbei. In vielen Bereichen wandert die Software ins Web. Auch auf Mobilgeräten werden die Browser immer leistungsfähiger und "Web-App-tauglicher". Leider macht das die Welt der Anwendungsentwickler nur wenig einfacher. Es herrscht immernoch eine große Fragmentierung an Geräteplattformen, die beherrscht werden muss. Außerdem unterscheiden sich mobile Web-Anwendungen enorm von "vollwertigen" Webanwendungen.
Die gerätespezifische Optik lässt sich meist mit CSS und JavaScript-Frameworks realisieren. Allerdings verlangt der große Unterschied zwischen Laptop/Desktop-PC und Mobiltelefon eine derartige Anpassung, wie sie mit CSS meist nicht realisierbar ist. Selbst wenn die Anpassung mit CSS möglich ist, werden auch die auf Mobilgeräten nicht angezeigten Elemente übertragen, was die Dateigröße unnötig aufbläht. Die Nutzung von CSS-Media-Queries verlangt außerdem eine recht grobe Verbiegung des Designs und moderne Browser auf den mobilen Endgeräten.
 |
| MVC-Pattern in Verbindung mit REST |
Diese Kombination schafft eine klare Struktur und hilft Entwicklern eine modulare, wartbare und leicht erweiterbare Software zu entwickeln. Teile davon wurden z.B. im Projekt "cocktailberater" umgesetzt. Hier gibt es mobile, Desktop, XML, PDF, RDF und RSS/Atom-Ansicht von verschiedenen Ressourcen.
Guter Artikel!
AntwortenLöschenAllerdings bevorzuge ich mittlerweile eher das Model View Presenter Pattern von Martin Fowler http://martinfowler.com/eaaDev/uiArchs.html als MVC. Bzw. in seinen neuen Varianten den Passive View und den Supervising Controller: http://martinfowler.com/eaaDev/ModelViewPresenter.html
Da gibt es keine Abhängigkeiten mehr zwischen Model und View, macht es meiner Ansicht nach einfacher zu ändern/erweitern.
Gibt dazu auch ein paar gute Möglichkeiten das mit Google Web Toolkit umzusetzen: http://code.google.com/intl/de-DE/webtoolkit/articles/mvp-architecture.html
Gruß,
Sven
P.S. Mach gerade ne Seminararbeit zum Thema GWT und MVP deswegen bin ich drauf gekommen ;-)
Danke für den Hinweis auf MVP, habe es mir eben kurz mal angeschaut.
AntwortenLöschenEs kommt glaube ich mehr aus der Desktop-Anwendungs-Ecke. Es macht die Entwicklung meiner Ansicht nach sehr aufwändig, nur um im Gegenzug die Abhängigkeit vom Model zum View zu entfernen um einen einfacheren Test zu ermöglichen.
Ich denke:
* oft sind die Models relativ stabil aber der View ändert sich häufig,
* schlanke Controller sind übersichtlicher zu warten und
* alle relevanten Informationen aus dem Model in String(-Arrays) zu extrahieren und teilweise View-Logik in den Controller zu übertragen ist nicht optimal.
Damit besteht aus meiner Sicht hier kein Grund MVP einzusetzen.
Ich habe auch schon eine kleine Anwendung mit GWT geschrieben und fand es ziemlich anstrengend. Vor allem wenn es nicht auf sehr gute Performance ankommt, ist Java, JS und HTML "selbercoden" die schnellere Alternative. Oder wie kommst du damit zurecht?
Sorry für die etwas verspätete Antwort, der Urlaub kam dazwischen ;-)
AntwortenLöschenAlso zu MVP:
- Fowler nennt unter anderem die bessere Testbarkeit als Vorteil, da der View ja nur noch GUI Elemente enthält und vom Presenter angesteuert wird und nicht mehr direkt mit dem Model kommuniziert, kann man die Views leicht durch Mock Objekte ersetzen und dann die Funktionalität vom Presenter/Model testen
- fand das Vorgehen etwas mehr straight forward, bei MVP hab ich mir immer gedacht, was pack ich nun in den View/Controller/Model und wann greift View auf Model etc. (aber das ist Geschmackssache)
- wie gesagt kommt es immer auf den Use Case an ;-)
Zu GWT:
- die Eingewöhnungszeit ist auf jeden Fall da und auch nicht unbedingt gering
- für kleinere Anwendungen ist Java/JS/HTML wenn man es beherrscht bestimmt häufig schneller
- find es aber ziemlich cool alles in Java zu machen - mein JS ist auch nicht das beste ;-)
- die Optimierung für jeden Browser ist ziemlich cool
- die GUI Elemente (vorallem mit Frameworks wie EXT GWT) sind echt gut zu gebrauchen
Wenn du willst kann ich dir gerne mal meine Seminararbeit schicken, wenn sie fertig ist, also spätestens in nem Monat ;-).
Gruß,
Sven