So erstellen Sie Enterprise Desktop-Anwendungen für Windows 8

Ich glaube, ich habe ein Gespür für die Erwartungen an die Entwicklung von Consumer-Anwendungen für Windows 8. Erstellen Sie eine neue Metro-basierte Benutzeroberfläche über WinRT, stellen Sie sie über den Marketplace für Ihre Kunden bereit, und alle profitieren. Scheint einfach genug. Leider bin ich nicht in diesem Geschäft.

Ich arbeite an internen Branchenanwendungen für ein großes Unternehmen. Derzeit verwenden wir .NET-Technologien wie WPF und Silverlight, um umfangreiche Benutzeroberflächen zu erstellen, die problemlos über das Web oder ClickOnce für unsere Benutzer bereitgestellt werden können. Die Anwendungen können WinXP und Win7 ohne allzu große Kopfschmerzen unterstützen, und unsere Entwickler können XAML verwenden, eine sehr solide UI-Technologie.

Anscheinend haben WPF und Silverlight zu diesem Zeitpunkt fragwürdige Zukunftsaussichten, daher ist es ein bisschen besorgniserregend, weiterhin in diese zu investieren. Eine Metro-Benutzeroberfläche scheint jedoch für Unternehmensanwendungen nicht geeignet zu sein, und die WinRT-API ist in Bezug auf "typische" Aufgaben, die Unternehmensanwendungen ausführen müssen, recht einschränkend.

Wie sollte ich meine XAML-basierten Anwendungen, die derzeit unter WinXP und Win7 bereitgestellt werden, architektonisch gestalten, damit sie unter Win8 unterstützt und weiterentwickelt werden können?

Nehmen Sie für die Zwecke dieser Frage an, dass die von HTML5 auf ASP.NET bereitgestellten Funktionen nicht für die Anwendungen geeignet sind, die ich erstellen möchte. Ich verstehe, dass ich HTML5 für einige Anwendungen verwenden kann, aber ich versuche herauszufinden, was ich tun soll, wenn das nicht ausreicht.

Edit # 1: Dies ist eine Antwort auf @Emmad Kareems Kommentar. Ich bin damit einverstanden, dass Silverlight / WPF kurzfristig (2-5 Jahre) lebensfähig sind. Die von uns hergestellten Anwendungen haben jedoch möglicherweise eine sehr lange Lebensdauer (10-20 + Jahre). Die langfristige Überlebensfähigkeit einer bestimmten Technologie ist uns ein Anliegen. Wir haben auch Bedenken, dass es immer schwieriger wird, Entwickler zu finden, die an der Entwicklung von Silverlight / WPF interessiert sind, wenn diese Technologien von der Community als "tot" eingestuft werden. Ich möchte nur meine Möglichkeiten verstehen und mit offenen Augen eine Entscheidung treffen.

Wie ich gelernt habe, mich nicht mehr zu sorgen und den MS-Stack zu lieben

Sie können weiterhin VB6-Apps unter Windows 8 ausführen . Retro-Kompatibilität für gut oder schlecht war schon immer ein Trend im MS-Ökosystem. Sie sollten sich keine Sorgen um das Überleben von Technologien wie WPF / Silveright und sogar Winforms machen.

Andererseits müssen Sie akzeptieren, dass Sie für ein langfristiges Projekt niemals die neueste, niedlichste Technologie haben werden.

Tatsächlich sollten Sie sich folgende Fragen zur Auswahl einer Technologie stellen:

• Fühlt sich mein Team mit dieser Technologie wohl, um produktiv zu sein?
• Ist mein Team glücklich, diese Technologie zu nutzen?
• Kann ich Leute für diese Technologie rekrutieren?

Das ist die Kombination der Antworten auf diese Fragen, die Ihre Wahl treffen sollten, und nicht die Trends, die hauptsächlich aus Marketinggründen gefälscht wurden.

Um mehr über dieses Thema der sich ständig ändernden Technologie zu erfahren , sollten Sie "Fire And Motion" von Joel Spolsky lesen :

Die Unternehmen, die stolpern, sind diejenigen, die zu viel Zeit damit verbringen, Teeblätter zu lesen, um die zukünftige Ausrichtung von Microsoft herauszufinden. Die Leute machen sich Sorgen um .NET und beschließen, ihre gesamte Architektur für .NET neu zu schreiben, weil sie denken, dass sie das müssen. Microsoft schießt auf Sie und es ist nur Deckfeuer, damit sie vorwärts gehen können und Sie nicht, denn so wird das Spiel gespielt, Bubby. Wirst du Hailstorm unterstützen? SEIFE? RDF? Unterstützen Sie es, weil Ihre Kunden es brauchen, oder weil jemand auf Sie schießt und Sie das Gefühl haben, reagieren zu müssen? Die Verkaufsteams der großen Unternehmen verstehen Deckfeuer.

Und das wurde vor fast zehn Jahren geschrieben.

Architektur und Technologien

Architektur und Technologien sind zwei getrennte Dinge und Möglichkeiten:

• Sie können MVC mit Winforms tun .
• Sie können MVVM mit WPF / Silverlight ausführen .
• Sie können MVC mit ASP.NET ausführen .
• Soweit wir wissen, können Sie mit WINRT alles tun, was Sie wollen, einschließlich MVC und MVVM .
• Sie können mit F # funktional gehen . Warum nicht ? Es gibt Bereiche, in denen es Sinn macht.
• Sie können sie alle mischen, um verschiedene Einstiegspunkte für ein gemeinsames System zu haben, und sich dann über etwas lustig machen, weil es zu kompliziert wird usw.

Mit all diesen Technologien können Sie Dienste, Ressourcen, Steuerelemente von Drittanbietern, ORMs usw. verwenden und mit den nächsten möglicherweise oder möglicherweise nicht.

Mit all diesen Technologien können Sie MVC auf viele Arten drehen und biegen: Binden oder nicht? Code hinter den Kulissen oder nicht? Controller oder nicht? ViewModel immer oder nur bei Bedarf? Es gibt so viele Möglichkeiten, ein Entwurfsmuster auch im Rahmen einer bestimmten Technologie zu implementieren.

Es wäre unrealistisch, Sie zu einem von ihnen zu zwingen, ohne über fortgeschrittene Kenntnisse Ihres Projekts und Ihres Teams zu verfügen. Es würde nur auf persönlichen Vorlieben basieren und in einem Showdown enden, bei dem "Meine Technologie ist besser als Ihre".

Das einzige, was ehrlich und objektiv vorgeschlagen werden kann, ist die Verwendung der besten Methoden, die Sie anwenden können, um eine Architektur zu erstellen, die den Test der Zeit bestehen wird und die möglicherweise wirklich portabel ist oder zumindest in Teilen mit einer zukünftigen unbekannten Technologie wiederverwendet wird . Und diese Aufrüstbarkeit / Portabilität sollte nicht einmal der Hauptzweck Ihrer Architektur sein.

Der Hauptzweck Ihrer Architektur und ausgewählten Technologie besteht darin, Ihrem Chef / Kunden ein Produkt zu liefern, das seinen realistischen Anforderungen entspricht.

MVC (und sein jüngerer Bruder MVVM) erwiesen sich seit 1979 immer mehr als Grundlage für robuste Architektur im Bereich der OOP-Sprachen und darüber hinaus. Die Wahl der Technologie, die in einem 10-jährigen Projekt eingesetzt werden soll, sollte jedoch Ihre Entscheidung bleiben.

Eine Sache, die ich in meinem Buch über MVVM ansprechen werde, ist, wie man das Muster nutzt, um eine wiederverwendbare Kernanwendung zu erstellen. Sie sollten eine native Benutzeroberfläche für die verschiedenen Plattformen erstellen, auf die Sie abzielen (Web, Silverlight, Telefon, WPF oder WinRT). Zum größten Teil können Sie jedoch die Logik für die Benutzeroberfläche hinter einem ViewModel einkapseln.

Alle Dienste, auf die Sie zugreifen, sollten sich hinter einer Schnittstelle (Fassadenmuster) befinden, die mehr oder weniger portabel zwischen Plattformen ist. Die Schnittstelle sollte auf der Vorderseite Ihrer Client-API zugeordnet und auf der Rückseite in die API des umschlossenen Service übersetzt werden.

Mit dieser Strategie können Sie ein solides Kernframework erstellen, auf das nur eine neue Benutzeroberfläche aufgeschichtet werden muss. Stellen Sie es sich als Ihr View Model vor, das die Muskeln und Ihre Dienste das Skelett (und die Organe) bilden. WPF / Silverlight / WinRT bilden die Skin.

In der Tat ist eine Sache, auf die ich sehr früh in meinem Buch hingewiesen habe, dass MVVM nicht so neu ist, wie es zu sein scheint. Dolphin Smalltalk hatte ein ähnliches Muster wie MMVC (die beiden M waren Anwendungsmodell und Domänenmodell). Das ViewModel, das wir heute verwenden, ist nur eine Kombination aus Anwendungsmodell und Controller von MMVC. Tatsächlich sind viele Entwickler der Meinung, dass es manchmal sinnvoll ist, das ViewModel in zwei Komponenten zu unterteilen (der Controller, der für die Navigation und das Orchestrieren mehrerer VMs verwendet wird, damit die VM andere Komponenten nicht erkennt).

Sie sagen, XAML sei solide, aber WPF habe eine fragwürdige Zukunft. Sofern ich nichts vermisse, verwendet WPF XAML und ich sehe nicht, dass die beiden jemals getrennt werden. Gibt es Neuigkeiten zu WPF, das möglicherweise eine andere Basistechnologie verwendet, oder zu Microsoft, das möglicherweise überlegt, eine weitere neue Methode zum Erstellen von Benutzeroberflächen zu entwickeln? Abgesehen davon bezweifle ich, dass WPF irgendwohin geht, aber es wäre nicht das erste Mal, dass MS Schiffsladungen unseres Codes überholt hat ...

Wenn Sie eine reichhaltige UI-App benötigen und HTML5 sie nicht schneidet und Ihre Organisation dem Windows-Betriebssystem verpflichtet ist, ist WPF meiner Meinung nach die beste Wahl, da es derzeit die neueste / beste ist, ganz sicher über Winforms ...

Ich gehe davon aus, dass Sie sich nicht zu sehr auf die Implementierungsdetails Ihrer Anwendungen konzentrieren sollten. Wenn Sie das Gesamtbild betrachten, können Sie Ihre Technologieabhängigkeiten eingrenzen. Indem Sie die Abhängigkeit von z. B. xaml / wpf / silverlight isolieren, stellen Sie sicher, dass Sie die UI-Komponente / -Technologie durch eine Technologie der nächsten Generation ersetzen können und somit die Kontinuität auch in 20 Jahren gewährleisten. Dies wird auch dazu beitragen, Ihre Systemkomponenten zu entkoppeln und die Auswirkungen eines solchen Austauschs zu vermeiden. (Dabei gehe ich davon aus, dass es in Ordnung ist, eine Lösung zu finden, um die Kontinuität auf einer Plattform der nächsten Generation zum Laufen zu bringen.)

Eine andere Möglichkeit, diese Technologieabhängigkeiten zu isolieren, ist die Aktivierung der Virtualisierung. Wenn Sie Ihre Anwendungen so erstellen, dass Sie sie in einem VM ausführen können, können Sie dies in 20 Jahren tun!