Komponentenorientiert vs. nicht komponentenorientiert

Streitgespräch
Kommentare

Komponente vs. Helper
Fastl:Lassen Sie mich einen Vergleich bringen, um die Sache deutlicher zu machen: Rails-Helper sind nicht anders als prozedurales Programmieren, eine richtige Objektorientierung lässt

Komponente vs. Helper

Fastl:Lassen Sie mich einen Vergleich bringen, um die Sache deutlicher zu machen: Rails-Helper sind nicht anders als prozedurales Programmieren, eine richtige Objektorientierung lässt sich erst durch Komponenten erzielen, die die Daten, für die sie zuständig sind, auch wirklich selbst verwalten können. Ein Rails-Helper kann mit den Daten, die durch ihn durchgeschleust werden, nicht wirklich viel anfangen, eine JSF-Komponente hat die volle Verfügungsgewalt über die zugehörigen Datenstrukturen.

Haimberger:

Wofür soll ein Helper seine zugehörigen Datenstrukturen verändern? Die Objektorientierung wird schließlich dadurch erzielt, dass die zugehörigen Daten in den „Models“ der Rails-Anwendung gekapselt sind. Da soll der Entwickler dann auch die Verwaltung der Daten vornehmen, dann kann er leicht andere Benutzer erreichen, nicht nur Web-Clients.

Fastl:Also so sehe ich das nicht. Es existiert auf jeden Fall Funktionalität, die in den Komponenten gekapselt sein soll und dort Sinn macht. Zum Beispiel ist es mit JSF ganz einfach, ein gültiges Modell hinter der Komponentenschicht zu erhalten; nur ein vollständig konvertierter und validierter Komponentenbaum wird ins Model übernommen. Viel wichtiger ist aber ganz einfach, dass die Verbindung zwischen Helper und zu veränderndem Model-Attribut explizit gemacht werden muss. Gerade bei der Verwendung von AJAX ist das eine fehlerträchtige Vorgangsweise. In JSF weiß die Komponente implizit über das zugehörige Model Bescheid. Für kleine Webanwendungen mag die erste Vorgangsweise noch funktionieren, für riesige Webanwendungen wird man aber unweigerlich Schiffbruch erleiden.

Haimberger:Es sei denn, das Projekt hat eine klar definierte und wohlüberlegte Richtlinie über Namenskonventionen, was Rails ohnehin schon vorgibt, durch das ins Framework integrierte Prinzip von „Convention over Configuration“.

Fastl:Es ist aber immer einfacher, wenn sich das Team nicht auf die Einhaltung von Konventionen verlassen muss, gerade bei großen, diversifizierten und räumlich getrennten Teams.

Haimberger:Die „Helper“ von Rails sind aber zweifellos einfacher zu verwenden und zu erstellen als die JSF-Komponenten. Ich bezweifle, dass die Einhaltung von Konventionen in Rails im Vergleich so viel schwieriger ist als die Verwendung von Komponenten gegenüber Helpern. Grundsätzlich sollte bei entsprechender Dokumentation die Einhaltung von Konventionen für die Projektmitglieder überhaupt kein Problem sein.

Fastl:Helper mögen vielleicht einfacher sein, die Komponenten von JSF erhöhen aber den Wiederverwendbarkeitsgrad von Webanwendungen. Module lassen sich damit besonders einfach erstellen und in anderen Webanwendungen neu einsetzen! In JSF kann sich ein Entwickler speziell auf die Komponentenentwicklung konzentrieren, dann ist die Komplexität kein Thema mehr, bei Rails muss jeder Seitenentwickler auch Ahnung vom AJAX-Ablauf haben.

Versuch eines Resümees

Die Wogen gehen hoch, und wie so oft bestätigt sich die Annahme, dass die Fronten zwischen den Anhängern von Webframeworks verhärtet sind. Je nachdem, wie die Projektanforderungen aussehen, kann die Bilanz bei der Verwendung der beiden Frame-works aber unterschiedlich ausfallen. Ein perfektes Framework für alle Anwendungen gibt es nicht. Für Rails und ein nicht komponentenorientiertes Framework spricht die niedrige Komplexität, der Einstieg ist einfach, es lassen sich schnell erste Erfolge mit AJAX erzielen. Ein komponentenorientiertes Framework wie JSF hilft aber bei größeren Projekten und Projekten mit Teams bei der einheitlichen Herangehensweise an die Lösung des Problems, AJAX vernünftig an den Client zu bringen. Die Einbindung von AJAX in Webanwendungen ist generell nicht einfach, Web-Frame-works tun aber alles dafür, diese Einbindung zu erleichtern. Sowohl Rails als auch MyFaces bieten hier eine volle Unterstützung an, der Level der Unterstützung, den komponentenorientierte Frameworks wie JSF bieten können, ist aber naturgemäß etwas größer, da hier sowohl das Rendering als auch der Postback von der Komponente selbst behandelt wird und mehr Funktionalität für den Benutzer weggekapselt bleibt. Dadurch, dass Rails eines der ersten Frameworks mit Unterstützung für AJAX war, ist aber ein gewisser Reifegrad zu spüren und damit ein Vorsprung, den MyFaces erst aufholen muss.

Ganz gleich, für welches Paradigma und welches Framework Sie sich entscheiden: wir wünschen Ihnen viel Spaß beim Einsatz von AJAX! Und wir hoffen natürlich, dass Sie Ihre Entscheidung entweder für Rails oder für MyFaces treffen werden.

Martin Marinschek, Ernst Fastl und Martin Haimberger arbeiten für das MyFaces und Rails Consulting- und Schulungsunternehmen IRIAN.at. Gemeinsam verfassen sie Bücher und Artikel zu diesen Frameworks. Martin Marinschek ist Committer und PMC-Member von Apache MyFaces.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -