Session Berichte–Teil 1

Heute Vormittag habe ich die Sessions zu MVVM++ und Continuous Deployment/Delivery besucht.

Continuous Deployment:

Persönlich empfand ich die Gespräche nicht zielführend, weil immer wieder die Gründe für den Einsatz von Versionskontrollsystemen und Buildservern angesprochen wurde. Es gab die verschiedensten Ausführungen, von wo man eigentlich kommt; den manuellen Builds (Stichwort: “Bei mir läuft’s doch”) der Anwendungen und dem XCopy-Austauschen von DLLs. Außerdem wurde primär über den TFS gesprochen. Hier zeichnet sich klar ab, dass so ziemlich jeder Kritikpunkte hat, die das tägliche Arbeiten erheblich stören. Meiner Meinung nach ist ein System, welches mir keinen Support für dezentrale Versionskontrollsysteme out of the box bietet, keine Empfehlung wert. In unserem Betrieb kommen Team City, YouTrack und Git im Verbund zum Einsatz. Ohne TFS eingesetzt zu haben, nahm ich die Situation so wahr, dass die Konfiguration und das Neuaufsetzen durch aus mehrere Tage in Anspruch nehmen könnte. Einig sind sich aber alle darin, dass es – egal welche Produkte zum Einsatz kommen – jederzeit möglich sein sollte, per Knopfdruck eine aktuell lauffähige Version auf die Clients zu deployen. Dabei ist Continuous Integration von Continuous Deployment dahingehend abzugrenzen, dass bei ersterem die Möglichkeit bestünde dies zu tun, bei letzterem es aber tatsächlich getan wird. Auch hier ist sollte man nochmal an die Verantwortlichen in den Unternehmen appellieren, dass sie eine entsprechende Infrastruktur schnellstmöglich einführen. Die Kosten, wenn denn welche entstehen (es gibt sehr viel Open Source Software), haben sich sehr schnell amortisiert.

 

MVVM++:

Auf der Session Wall finden sich aus gutem Grund – wie ich finde – viele UI Themen. MVVM++ ging hier primär auf entsprechende Frameworks und das Integrieren in einer modularen Anwendung ein. Neben Anfängern saßen auch erfahrene Profis im Raum. Die Gespräche waren imho sehr lohnend. So konnte abgegrenzt werden, dass Prism als sehr komplexes Framework klar von MVVM Light und Caliburn.Micro abzugrenzen ist. Im gleichen Kontext musste klar gestellt werden, dass modulare UIs (korrekt wäre Composite UI) zunächst einmal nichts mit einer modularen Architektur, wie sie durch die Verwendung von IoC Containern möglich werden, zu tun haben. Zusammenfassend lässt sich in jedem Fall sagen, dass Technologieentscheidungen betriebswirtschaftlich getrieben sein sollten. Wenn der Kunde eine Composite UI benötigt und auch bereit ist hierfür Geld in die Hand zu nehmen, dann verwende ich Prism. Soll hingegen der Overhead durch MVVM auf Basis von Konventionen reduziert werden, so ist Caliburn.Micro völlig ausreichend. Außerdem ist es eine Frage des Wissenstandes: Im Zweifel mit weniger komplexen Frameworks einsteigen!

Über IoC habe ich inzwischen mehrfach gebloggt und auch einen Webcast aufgenommen.

Mit Tag(s) versehen: , ,

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: