Sollte mein C# .NET-Team zu Windows Presentation Foundation migrieren?

Question

Wir erbringen Infrastrukturdienste (Datenabruf und -speicherung) und kleine intelligente Client-Anwendungen (vor allem ausgefallene Berichte) für eine Geschäftsbank. Unser Team ist groß, ca. 40 Vertragsangestellte, die C# .NET-Programmierer sind. Wir unterstützen etwa 50 Anwendungen und Systeme, die wir entwickelt haben.

Einige Mitglieder des Teams begannen mit der Herstellung von WPF , WF y WCF basierten Anwendungen. Da sie die ersten sind, verstehen die meisten Mitglieder diese Technologien nicht. Welche Vorteile bieten sie, die die Kosten für die Umschulung des Teams aufwiegen würden?

Answer 1

Wir sind gerade dabei, ein Projekt abzuschließen, in dem ich und 4 andere eine ziemlich erfolgreiche, verteilte Unternehmensanwendung entwickelt haben. Wir begannen mit Win32 und wechselten dann nach der ersten Iteration zu WPF, um die Anforderungen unseres Usability-Experten zu erfüllen. Hier ist meine Erfahrung.

WPF hat einige wirklich großartige Funktionen. Im Allgemeinen macht es die wirklich schwierigen Dinge trivial (wie die Erstellung von Listboxen, die reiche Präsentation Daten, wie Bilder mit Tabellen, Kopie, etc. gemischt zeigen), aber im Gegenzug kann die "dies verwendet werden, um so einfach in Win32" schmerzlich frustrierend sein. Ich habe in WPF für 6 Monate jetzt arbeiten, und ich finde immer noch Databinding eine Combobox zu einem XML-Dataprovider eine gefürchtete Erfahrung.

Wie ich oben angedeutet habe, hat WPF einige große und nicht so große Bindung. Ich liebe, wie Sie zu einem XML-Dokument oder Inline-Fragment mit binden können XPath aber ich hasse es, dass man die eingebauten Bindungsvalidierungen nur verwenden kann, wenn die Bindung zweiseitig ist (und ich hasse es doppelt, dass man die eingebauten Bindungsvalidierungen nicht dazu zwingen kann, Benutzereingaben an das Objekt zurückzugeben, selbst wenn die Daten außerhalb des Bereichs einer Geschäftsregel liegen).

WPF hat eine enorme Lernkurve. Es ist nicht einmal eine Kurve - es ist eine Wand. Es ist ein harter Weg. Es ist eine völlig andere Art der Arbeit mit Windows-Präsentation, und für mich jedenfalls, es erforderte eine Menge lesen und spielen, bevor ich begann, etwas bequem zu fühlen. Es ist nicht die einfachste Sache der Welt, aber man kann damit einige unglaublich mächtige Dinge tun (z. B. habe ich in unserem Projekt eine Formular-Engine erstellt, die vollwertige XAML-Formulare aus XML mit etwa 300 Zeilen von XSLT - komplett mit vollständiger Bindung und Validierung).

Insgesamt bin ich sehr zufrieden, dass wir uns für XAML entschieden haben, trotz der Lernkurve, der etwas fehleranfälligen Natur des Ganzen und einiger tiefer Frustrationen. Die positiven Aspekte haben die negativen bei weitem überwogen und es hat uns ermöglicht, Dinge zu tun, die ich nicht für möglich gehalten hätte, ohne dass die Leistung enorm darunter gelitten hätte.

Wenn Sie sich entscheiden, den Weg der WPF zu gehen, würde ich diese 2 Bücher sehr empfehlen:

• Windows Presentation Foundation Unleashed von Adam Nathan ist eine großartige Einführung, die in Farbe erscheint! Es liest sich wie ein Blog und gibt Ihnen eine großartige Einführung - http://www.amazon.ca/Windows-Presentation-Foundation-Unleashed-WPF/dp/0672328917/ref=pd_ys_iyr3

• Programming WPF: Building Windows Ui with Windows Presentation Foundation, von Chris Sells. Mehr Details und ein großartiges Buch, das die WPF Unleashed - http://www.amazon.co.uk/Programming-WPF-Building-Presentation-Foundation/dp/0596510373

Viel Glück!

Answer 2

WPF-Benutzeroberflächen sind einfacher zu entwerfen, zu implementieren und zu warten als die aktuellen C#-Alternativen. Wenn also ein großer Teil Ihrer Codebasis für die Handhabung der Benutzeroberfläche verantwortlich ist, kann die Migration von Vorteil sein - Sie werden feststellen, dass Ihr Team bei der Arbeit mit der Benutzeroberflächenschicht Zeit sparen wird. Wenn der größte Teil Ihres Codes aus Geschäftslogik besteht, wird die Migration nicht so viel bringen.

Answer 3

Mit WPF kann man einige erstaunliche Dinge tun, und ich LIEBE es... aber ich fühle mich immer verpflichtet, meine Empfehlungen zu relativieren, wenn Entwickler mich fragen, ob ich denke, dass sie auf die neue Technologie umsteigen sollten.

Sind Ihre Entwickler bereit (vorzugsweise EAGER), die Zeit zu investieren, die nötig ist, um zu lernen, wie man WPF effektiv nutzt? Ich wäre nie auf die Idee gekommen, dies über MFC oder Windows Forms oder sogar unmanaged DirectX zu sagen, aber Sie wollen wahrscheinlich NICHT, dass ein Team versucht, WPF im Laufe eines normalen Entwicklungszyklus für ein Produkt zu "erlernen"!

Haben zumindest ein oder zwei Ihrer Entwickler ein gewisses Gespür für Design und verfügen die Personen mit der endgültigen Designkompetenz über ein angemessenes Verständnis für Entwicklungsfragen, so dass Sie die WPF-Funktionen nutzen können, um etwas zu erstellen, das tatsächlich BESSER ist, anstatt nur "bunter" zu sein und überflüssige Animationen zu enthalten?

Läuft ein gewisser Prozentsatz Ihrer Zielkundenbasis mit integrierten Grafikchipsätzen, die die von Ihnen geplanten Funktionen möglicherweise nicht unterstützen - oder läuft dort noch Windows 2000, wodurch sie als Kunden völlig ausscheiden würden? Einige Leute würden auch fragen, ob Ihre Kunden sich tatsächlich für eine verbesserte Grafik interessieren, aber da ich in den frühen 90er Jahren unternehmensinterne "Unsere Geschäftskunden interessieren sich nicht für Farben und Bilder"-Debatten miterlebt habe, weiß ich, dass gut konzipierte Lösungen Ihrer Konkurrenten sie dazu bringen werden, sich dafür zu interessieren, und die eigentliche Frage ist, ob die Bedingungen richtig sind, damit Sie etwas anbieten können, das sie JETZT interessiert.

Beinhaltet das Projekt eine grundlegende Entwicklung, zumindest für die Präsentationsschicht, um die zusätzliche Komplexität zu vermeiden, die durch den Versuch entsteht, sich in inkompatible Legacy-Gerüste einzuklinken (die Interoperabilität mit Windows Forms ist NICHT nahtlos)?

Kann Ihr Vorgesetzter einen erheblichen RÜCKGANG der Entwicklerproduktivität über vier bis sechs Monate hinweg akzeptieren (oder davon ablenken, ihn zu bemerken)?

Dieses letzte Problem ist auf das zurückzuführen, was ich gerne als die "FizzBin"-Natur von WPF bezeichne. Es gibt zehn verschiedene Möglichkeiten, eine Aufgabe zu implementieren, und es gibt keinen offensichtlichen Grund, einen Ansatz einem anderen vorzuziehen, und es gibt kaum Anleitungen, die Ihnen bei der Auswahl helfen. Nicht nur, dass die Unzulänglichkeiten der von Ihnen getroffenen Wahl erst viel später im Projekt deutlich werden, sondern es ist auch so gut wie sicher, dass jeder Entwickler in Ihrem Projekt einen anderen Ansatz wählt, was zu großen Wartungsproblemen führt. Am frustrierendsten sind jedoch die Ungereimtheiten, die Ihnen beim Erlernen des Frameworks ständig in die Quere kommen.

Ausführlichere Informationen zu WPF finden Sie in einem Eintrag in meinem Blog:

http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx

Answer 4

WPF:

• Alles dreht sich um die Grafik!
• ist ein auflösungsunabhängiges Framework (d.h. WPF hat das Konzept der Vektorgrafik vollständig übernommen - und hat auch die Skalierung von Bitmap-Grafiken zu einem rücksichtslosen Prozess gemacht)
• Ist hardwarebeschleunigt!!!! WPF-Grafiken sind hardwarebeschleunigt, wenn möglich durch Direct3D - es ist NICHT GDI basiert!
• Hat keine Paint() Funktion - WPF basiert auf einem beibehaltenen Grafikmodus / baumbasierten Zeichensystem. Endlich!
• Ist grafisch sehr dynamisch - alles kann animiert werden - und die Animation ist in den Rahmen eingebaut. Zur Erinnerung.... gibt es keine Paint() !
• Ist extrem anpassungsfähig - auch wenn man sich mit den Feinheiten der ControlTemplates ist der Punkt, an dem die Komplikation beginnt. Sie fügen dem Anzeigebaum einfach Objekte hinzu und überlassen WPF die Aktualisierung.
• Ist sehr reich an Funktionen zur Textdarstellung.
• hofft, den Arbeitsablauf des Designers/Codierers durch die Verwendung einer deklarativen Sprache zu verbessern ( XAML ) für grafische Definitionen und komplexe GUI-Designsoftware ( Expression Blend ). Es ist jedoch wichtig zu erkennen, dass alles, was auf deklarative Weise getan werden kann, auch im Code erreicht werden kann. Und es ist auch fraglich, ob die Komplexität von WPF viele Designer abgeschreckt hat - aber es hat ein leistungsstarkes Framework in die Hände von Programmierern gelegt.

WPF:

• Ist NICHT Windows-Formulare ++ - es ist einfach ein völlig anderes Konzept
• Ist NICHT Silverlight - Silverlight ist eine Untermenge von WPF. Eine ziemlich leichte Untermenge.
• Ist NICHT MFC - OK, das sollte offensichtlich sein
• Kann nicht ohne Weiteres mit Windows XP verteilt werden - das ist eine Schande und vielleicht einer der größten Fehler.
• Ist nicht XAML. Dieser Unterschied muss verstanden werden. XAML ist ein optional deklarative Sprache, die im Entwicklungsprozess von WPF-Anwendungen verwendet werden kann. Sie ist absolut keine notwendige Komponente, aber wenn man sie einmal verstanden hat, verbessert sie definitiv den Arbeitsablauf, das Design und das Refactoring von komplexen grafischen Frameworks.

Answer 5

WPF unterscheidet sich grundlegend von Windows Forms. Das bedeutet einen hohen Schulungsaufwand für Ihr Team.