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.

Werbung

Workshop – Eine Zeitreise mit dem Desktop Teil 2

Nachdem ich in Teil 1 die aktuell zur Verfügung stehenden Technologien angesprochen habe, soll es nun mehr um Patterns und Clean Code Prinzipien schlechthin gehen.

Während WinForms mit seinem Code Behind in keinster Weise den Anforderungen an die Evolvierbarkeit von Code genügt, wurde mit WPF von Anfang an eine leichte Abwandlung des MVC/MVP Patterns “vermarktet”: Das Model View ViewModel Pattern.

Frank und Silvio stellen hierbei das Seperation of Concerns Principle in den Vordergrund. Besonders gut gefallen hat mir in diesem Kontext auch deren Haltung zu Domain Driven Design. Wie ich, haben sie eine von der ursprünglichen Lehre Evans abweichende Meinung bgzl. der Vermischung von Daten und Logik im selben Objekt. Ralf Westphal hat dies in den vergangenen 6 Monaten ebenfalls in einer 3-teiligen Serie in der dotnetpro (in den Heften 4, 6 und 7 2012) thematisiert.

Anmerkung: Auf dem im Juli stattgefundenen .NET Open Space Süd kam im Übrigen selbige Diskussion. Deshalb an dieser Stelle meine Aufforderung an die Community hierüber vermehrt zu bloggen.

Leider hat MVVM auch diverse Nachteile, darunter das häufige Wiederholen von gleichem bzw. ähnlichem Code. Nachdem kurz über diverse MVVM Frameworks gesprochen wurde, stellten die Referenten eine von ihnen entwickelte im Produktiveinsatz befindliche Lösung vor, die mit ca. 1000 Codezeilen recht überschaubar ist. Laut Aussagen haben sie sich dafür die Schmerzstellen in den eigenen Projekten angeschaut und das Beste für sich aus den verschiedenen Frameworks herausgepickt.

Den Code werde ich, nachdem die Zwei das Feedback des Workshops eingearbeitet haben, mit deren freundlicher Erlaubnis hier online stellen.

Workshop – Eine Zeitreise mit dem Desktop Teil 1

Am vergangenen Freitag, d.h. ziemlich genau eine Woche vor der NRW Conf, haben sich Frank Pfattheicher und Silvio Katzmann freundlicherweise bereit erklärt, ihren Workshop ‘Eine Zeitreise mit dem Desktop’ in abgespeckter Form für mich und ein paar weitere Auserwählte abzuhalten. Der Workshop thematisiert die aktuellen Oberflächen-Technologien für den Desktop Bereich. Angefangen bei dem Klassiker WinForms, über WPF bis hin zum brandaktuellen Modern UI auf Basis von XAML und C# (als ein Vertreterpaar, siehe Bild).

Der Workshop beinhaltet zunächst ein kurzes Für und Wider der jeweiligen Technologien. Das Resümee entspricht dem, wie es vermutlich aktuell die meisten Entwickler sehen:

• WinForms: Für bestehende Anwendungen, Remote Desktop Szenarien (WPF hat hier Probleme) und für ältere Betriebssysteme wie Windows 2000
• WPF: Für neue Anwendungen, stark multimediale Szenarien (oder Spiele) und bei Bedarf zur Kollaboration von Entwickler und Designer
• Silverlight: De facto am Ende
• Modern UI: Für Windows 8 App Entwickler

Da mir die Technologieauswahl essentiell erscheint, möchte ich näher darauf eingehen:

WinForms wird früher oder später aufgegeben. Allerdings erkennt man anhand der Community Feature Wunschliste für VS2012, dass hier noch lange Support erwartet wird. Darüber hinaus zeichnet sich ab, dass es eher später, als früher fallengelassen wird. Speziell bei Remote Desktop Anwendungen führt aktuell kein Weg daran vorbei, da WPF auf Grund der technischen Implementierung (DirectX statt GDI) hierfür zu langsam ist. Einen entsprechenden Artikel gab es vor geraumer Zeit in der dotnetpro.

WPF scheint aktuell die beste Wahl zu sein, wenn es darum geht neue Applikationen zu schreiben. Allerdings ist der kleine Bruder Silverlight bereits zu Grabe getragen worden und hin und wieder zeichnen ehemalige Mitarbeiter von Microsoft ein eher trübes Bild, wohin die Reise geht. Microsoft hat bis auf wenige Ausnahmen (z.B. mit Visual Studio) selbst kaum Produkte im Sortiment, die WPF nutzen. Auch das ist kein positives Zeichen. Auch ein besonders für mich persönlich schlagkräftiges Kriterium, nämlich der oft versprochene Designer-Developer-Workflow, stellt sich in der Praxis laut besagten Referenten nicht ein und ist wenn überhaupt nur innerbetrieblich mit stark zusammenhängenden Teams zu erreichen. Der Vollständigkeit halber sei noch angemerkt, dass sobald man Komponenten von Drittherstellen (wie DevExpress) einsetzt, es sich sowieso nicht mehr um WPF Controls handelt und dass ggf. Designer Werkzeuge wie Expression Blend Probleme haben können.

Zu guter Letzt bleibt Modern UI mit unterschiedlichen Lösungsansätzen. Aktuell kann man sicherlich sagen, dass die Zukunft ungewiss ist. Gemäß dem, wie ich die Stimmung bisher in der Community bisher empfinde, sieht es hier noch nicht rosig aus. Da wir aber von “Kachel”-Apps sprechen, ist diese Technologie sowieso für ERP-Systeme und ähnlich Geschäftsanwendungen nicht praktikabel.  Ganz abgesehen davon, ist der Code nicht kompatibel zu den .NET APIs. Inwieweit die gleiche Code Basis für Windows Phone 8 verwendet werden kann, ist ebenfalls fraglich. Gerade dieser Punkt, nämlich Write Once Run Anywhere, wäre für mich ein Killer Argument für das neue Framework gewesen.

Alles in allem sind sich die Referenten und ich uns einig, dass XAML bzw. die Konzepte und der Aufbau dahinter, sicherlich überleben werden. Demzufolge ist die Einarbeitung in XAML keine vergeudete Zeit. Wie es denn nun mit den Oberflächen für den Desktop weitergeht, ist unklar. Hier sind wir sicherlich nicht die Einzigen, die sich eine konkrete Aussage von Microsoft wünschen.

Beim hoffentlich im November stattfindenden Hackathon in Karlsruhe werde ich versuchen die Meinung anderer Developer einzufangen. Außerdem verweise ich noch auf zwei Artikel von mir:

• MVVM & WPF auf dem Prüfstand Teil 1
• MVVM & WPF auf dem Prüfstand Teil 2

 

Teil 2 des Serie gibt es jetzt hier.

MVVM & WPF auf dem Prüfstand–Teil 2

In meinem ersten Beitrag habe ich bereits einige wesentliche Punkte genannt, die es zu evaluieren gilt. Beim Hackathon konnte ich langjährige und erfahrene Entwickler im WPF-MVVM-Bereich darauf ansprechen. Zunächst einmal ist der Grundgedanke weiterhin der, dass zu prüfen ist, ob man die Vorteile von MVVM überhaupt nutzt. Falls dem nicht der Fall ist, bedeutet das nicht notwendigerweise, dass deshalb MVVM ausscheiden muss. Dem liegt die Prämisse zu Grunde, dass die Komplexität und konsequenterweise die damit einhergehende Development Velocity nicht weniger produktiv (d.h. betriebswirtschaftlich rentabel) ist, als wenn ich beispielsweise mit Code Behind arbeiten würde. Hier sind 3 wesentliche Punkte zu nennen:

• Data Binding: Dies ist sicherlich deutlich schwieriger mit Code Behind zu implementieren
• Designer Workflow: Expression Blend fällt bei Code Behind in jedem Fall aus. Da Expression Blend deutlich schneller als der VS Designer ist und darüber hinaus Unterstützung für Modellierung mit Live Daten bietet, ist hier mit Sicherheit mit Zeiteinsparungen zu rechnen.
• Team Arbeit: Durch den Einsatz eines verbreiteten, standardisierten Patterns gestaltet sich die Zusammenarbeit einfacher und vermutlich auch effektiver. Ein neuer Developer, der das Pattern kennt, dürfte auch schneller einzuführen sein.

Trotzdem gilt zu bedenken, dass ohne entsprechende Dritthersteller-Frameworks wie Caliburn.Micro, die einem das Groß an Infrastruktur Programmierung abnehmen, nur selten effektiver und somit rentabel gearbeitet werden kann. Wer auf Grund der Rahmenbedingungen hierauf verzichten muss, sollte sich also überlegen, ob MVVM für ihn sinnvoll ist. Es sei aber auch angemerkt, dass mit relativ einfachen Mitteln entsprechende Funktionalität selbst implementiert werden kann.

MVVM & WPF auf dem Prüfstand

Wer mit dem Gedanken spielt die WPF in Verbindung mit dem MVVM Pattern einzusetzen, sollte zunächst kurz stehen bleiben und überlegen, was er erreichen will:

• Will ich die Oberfläche automatisiert testen
• Will ich die UI austauschen und z.B. eine zusätzliche Webschnittstelle mit HTML zur Verfügung stellen
• Will ich gleichzeitig an der UI designen und am Code entwickeln können, z.B. durch ein Marketing und ein Entwickler Team

Das sind die 3 wesentlichen Akzeptanztests, die den Ausschlag für oder gegen WPF und MVVM geben.

Wer keine Tests schreiben will, der verliert bereits einen wesentlichen Punkt, denn der Grundgedanke hinter MVVM war besagtes Testen. Persönlich würde mich interessieren wie viele MVVM einsetzen und dementsprechend die Tests schreiben. Diejenigen, die lediglich mit Wechselgedanken spielen, denen könnte man empfehlen sich die Testabdeckung für die Geschäftslogik anzuschauen. Ist diese sehr moderat bis hin zu gänzlich fehlend, so ist nicht davon auszugehen, dass der Punkt umgesetzt werden würde.

Bleibt die lose UI Kopplung als weiterer Punkt. Sicherlich nicht unwichtig, bedenkt man, dass webbasierter und mobiler Zugang zu Applikationen ganz sicher die Zukunft gehört. Bestes Zeichen hierfür: Neue Windows 8 Apps können nur noch mit XAML oder HTML5 entwickelt werden. Allerdings könnte in diesem Fall, um zwei Alternativen zu nennen, vielleicht auch auf ASP.NET mit MVC oder auf WPF mit Code Behind gesetzt werden.

Der letzte und für mich persönlich mindestens genauso wichtige Akzeptanztest ist die Möglichkeit Designer an die Oberfläche zu setzen, während man als Entwickler seinem Hauptgeschäft nachgehen kann: Geschäftsprozesse implementieren und optimieren. Was hier bereits mit Expression Blend oder ähnlichen Tools bereits möglich ist, kann ich nicht sagen, allerdings finde ich den Gedanken charmant! Nero hatte hierzu einmal einen Praxisbericht gegeben – damals noch mit Version 2 von Expression. Falls dies ein Entwickler aus Karlsbad liest: Wie ist der aktuelle Stand? Wie ich allerdings bei mir im Betrieb feststellen musste, sind die Hemmnisse – sowohl auf Seiten der Designer in der Marketingabteilung, als auch auf Seiten der Entwicklerkollegen – hier noch recht hoch. Primär wird daran gezweifelt, ob dies technisch überhaupt ohne größere Schwierigkeiten funktioniert (Stichwort Mock-Daten) und ob man als Entwickler dieses Mittel der Steuerung aus der Hand geben sollte. Inwieweit weniger IT-affine Designer überhaupt dazu in der Lage wäre, steht auch einer anderen Seite.

Sind alle 3 Punkte zu verneinen, so rechtfertigt der Mehraufwand und der Einkauf von Komplexität sicherlich nicht den Einsatz. In diesem Fall kann man – ohne sich schämen zu müssen – durchaus auch über WPF mit Code Behind nachdenken.