Künftige Proofing einer großen UI-Anwendung - MFC mit Feature Pack 2008 oder C# und Winforms?

Question

Meine Firma hat ein langjähriges Produkt entwickelt, das MFC in Visual C++ als Defacto-Standard für die UI-Entwicklung verwendet. Unsere Codebasis enthält ALOT von altem/archaischem Code, der betriebsbereit gehalten werden muss. Einige dieser Code ist älter als ich (ursprünglich in den späten 70ern geschrieben) und einige Mitglieder unseres Teams sind immer noch auf Visual Studio 6.

Allerdings ist eine Schlussfolgerung glücklicherweise intern erreicht worden, dass unser Produkt etwas antiquiert im Vergleich aussieht zu unseren Wettbewerbern, und dass etwas getan werden muss.

Ich arbeite derzeit an einem neuen Bereich der Benutzeroberfläche, die vom Rest des Produkts ziemlich getrennt ist. Ich habe daher die Chance bekommen, "neue" Technologie-Stacks als eine Art Teststrecke auszuprobieren, bevor der lange Prozess der Bewegung über den Rest der Benutzeroberfläche beginnt.

Ich habe C# mit Windows Forms und dem .net Framework für eine Weile in meiner Freizeit verwendet und genieße es, bin aber etwas besorgt über die Kopfschmerzen, die durch Interop verursacht werden. Während dieser spezielle Zweig der Benutzeroberfläche nicht viel Interop mit der älteren C++ - Codebasis benötigt, kann ich vorhersehen, dass dies in Zukunft ein Problem wird.

Die Alternative besteht nur darin, mit MFC fortzufahren, aber versuchen Sie, das neue Feature Pack zu nutzen, das mit VS2008 ausgeliefert wurde. Dies ist wahrscheinlich die einfachste Option, aber ich mache mir Sorgen über die Langlebigkeit und nicht die Vorteile der Güte, die ist .net ...

Also, welche nehme ich? Wir sind ein kleines Team, daher wird meine Empfehlung wahrscheinlich als zukünftige Richtung für unsere Entwicklung akzeptiert werden - ich will es richtig machen.

Ist MFC tot? Ist C#/Winforms der Weg nach vorne? Gibt es noch etwas, das ich völlig vermisse? Hilfe sehr geschätzt!

Answer 1

Ich bin ein Entwickler auf einer App, die eine Tonne von altem MFC-Code hat, und wir haben alle Ihre gleichen Bedenken. Ein großer Treiber für unsere Strategie war, so viel Risiko und Ungewissheit wie möglich zu eliminieren, was bedeutete, The Big Rewrite zu vermeiden. Wie wir alle wissen, scheitert TBR die meiste Zeit. Daher haben wir einen inkrementellen Ansatz gewählt, der es uns ermöglicht, Module zu erhalten, die sich in der aktuellen Version nicht ändern werden, neue verwaltete Funktionen zu schreiben und Funktionen zu portieren, die Verbesserungen für die Verwaltung erhalten.

Sie können dies mehrere Möglichkeiten:

1. Host-WPF-Inhalte auf Ihrem MFC Ansichten (siehe here)

2. für MFC MDI-Anwendungen, erstellen Sie einen neuen Rahmen WinForms und hosten Ihre MFC MDI Ansichten (siehe here)

3. Host-WinForms-Benutzersteuer in MFC Dialoge und Ansichten (siehe here)

Das Problem mit der Annahme von WPF (Option 1) ist, dass Sie alle Ihre UI auf einmal umschreiben müssen, sonst wird es ziemlich schizophren aussehen.

Der zweite Ansatz sieht praktikabel, aber sehr kompliziert aus.

Der dritte Ansatz ist der, den wir ausgewählt haben, und es hat sehr gut funktioniert. Es ermöglicht Ihnen, Bereiche Ihrer App selektiv zu aktualisieren, während die Gesamtkonsistenz erhalten bleibt und nicht unbrauchbare Dinge berührt werden.

Das Visual C++ 2008 Feature Pack sieht interessant aus, aber ich habe damit noch nicht gespielt. Scheint, als könnte es mit Ihrem Problem des veralteten Aussehens helfen. Wenn die "Multifunktionsleiste" für Ihre Benutzer zu erschütternd wäre, könnten Sie sich an Drittanbieter-MFC- und/oder WinForms-Steuerungsanbieter wenden.

Meine allgemeine Empfehlung ist, dass interop + inkrementelle Änderungen definitiv zu umfassenden Änderungen vorzuziehen ist.

---

nach dem Follow-up zu lesen, kann ich auf jeden Fall, dass die Produktivitätsgewinne des Rahmens bestätigen in beträchtlichem Ausmaß die Investition in das Lernen es überwiegen. Niemand in unserem Team hatte zu Beginn dieser Bemühungen C# verwendet und jetzt bevorzugen wir es alle.

Answer 2

Wenn Sie auf C# und damit auf .NET verschieben, würde ich Windows Presentation Foundation statt WinForms betrachten. WPF ist die Zukunft intelligenter Clients in .NET und die Fähigkeiten, die Sie sammeln, können Sie wiederverwenden, wenn Sie von einem Browser gehostete Silverlight-Anwendungen erstellen möchten.

Answer 3

Ich stimme der WPF-Stimmung zu. Die Tag/XML-basierte Benutzeroberfläche scheint etwas portabler zu sein als WinForms.

Ich denke auch du musst dein Team berücksichtigen, wenn es nicht viele aktuelle C# Skills gibt, dann ist das ein Faktor, aber der Markt für MFC Entwickler schreitet immer kleiner und C# wächst.

Vielleicht wäre eine Art stückweiser Ansatz möglich? Ich habe viel mit der Umcodierung von Legacy-Anwendungen in C# zu tun, und es dauert immer viel länger, als Sie schätzen würden, besonders wenn Sie Legacy-Code behalten oder Ihr Team mit C# nicht so vertraut ist.

Answer 4

Abhängig von der Anwendung und der Bereitschaft Ihrer Kunden, .NET zu installieren (nicht alle von ihnen), würde ich definitiv zu WinForms oder WPF wechseln. Interop mit C++ - Code wird durch die Umgestaltung von Nicht-UI-Code in Klassenbibliotheken mit C++/CLI (wie Sie bei der Auswahl von Tags bemerkt haben) enorm vereinfacht.

Das einzige Problem mit WPF ist, dass es schwierig sein kann, das aktuelle Look-and-Feel beizubehalten. Der Wechsel zu WinForms kann unter Beibehaltung des aktuellen Aussehens Ihrer GUI erfolgen. WPF verwendet ein so unterschiedliches Modell, dass der Versuch, das aktuelle Layout beizubehalten, wahrscheinlich sinnlos wäre und definitiv nicht im Sinne von WPF wäre. WPF hat anscheinend auch schlechte Leistung auf Pre-Vista-Computern, wenn mehr als ein WPF-Prozess ausgeführt wird.

Mein Vorschlag ist es, herauszufinden, was Ihre Kunden verwenden.Wenn die meisten nach Vista umgezogen sind und Ihr Team bereit ist, viel GUI-Arbeit zu leisten, würde ich WinForms überspringen und zu WPF wechseln. Ansonsten schau dir WinForms definitiv mal ernsthaft an. In beiden Fällen ist eine Klassenbibliothek in C++/CLI die Antwort auf Ihre Interop-Probleme.

Answer 5

Sie geben nicht viele Details darüber, was Ihr Legacy-Code tut oder wie er strukturiert ist. Wenn Sie bestimmte Leistungskriterien haben, möchten Sie möglicherweise einige Ihrer Codebasis in C++ beibehalten. Sie werden es leichter haben, mit Ihrem alten Code zu interoperieren, wenn er richtig dargestellt wird - können Sie heute von C# in die bestehende Codebasis anrufen? Vielleicht lohnt es sich, über ein Projekt nachzudenken, um diese Struktur richtig zu machen.

In Bezug auf WPF könnte man argumentieren, dass WinForms möglicherweise besser geeignet sind. Der Wechsel zu WinForms ist ein großer Schritt für Sie und Ihr Team. Vielleicht sind sie vielleicht mit dem Wechsel zu WinForms vertrauter? Es ist besser dokumentiert, mehr Erfahrung auf dem Markt und nützlich, wenn Sie noch Windows 2000-Clients unterstützen müssen.

Sie könnten sonst in Extending MFC Applications with the .NET Framework

Etwas interessiert sein, zu prüfen C++/CLI, aber ich habe keine Erfahrung damit.

Answer 6

Vielen Dank für Ihre Antworten, es ist beruhigend zu sehen, dass im Allgemeinen der Konsens meiner Linie folgt. Ich bin in der glücklichen Situation, dass unsere Software auch auf unserer eigenen Hardware läuft (für die Broadcast-Industrie) - also ist die Wahl des Betriebssystems wirklich unsere und wird von unseren Kunden angenommen. Momentan läuft XP/2000, aber ich sehe bald den Wunsch, nach Vista zu wechseln.

Allerdings müssen wir auch sehr genaue Kontrolle über die GPU-Leistung behalten, was automatisch WPF und Hardwarebeschleunigung ausschließt? Ich hätte diesen Punkt in meinem ursprünglichen Beitrag erwähnen sollen - Entschuldigung. Vielleicht ist es möglich, zwei GPUs zu verwenden ... aber das ist eine andere Frage insgesamt ...

Das Team hat keine signifikanten C# -Erfahrung und ich bin kein Experte selbst, aber ich denke, die langfristigen Vorteile von insgesamt Die verwaltete Umgebung überwiegt wahrscheinlich die Zeit, die benötigt wird, um auf dem neuesten Stand zu sein.

Sieht aus wie Winforms und C# haben es für jetzt.