Zukunft proofing ein großes UI-Anwendung - MFC-2008 Feature pack, - oder C# - und Winforms?

StackOverflow https://stackoverflow.com/questions/10901

Frage

Mein Unternehmen hat eine langjährige Produkt-Verwendung von MFC in Visual C++ als de-facto-standard für die UI-Entwicklung.Unsere Codebasis enthält eine Menge von legacy/archaische code muss funktionsfähig gehalten.Einige der in diesem code ist älter als ich (ursprünglich geschrieben in den späten 70er Jahren) und einige Mitglieder unseres Teams sind noch auf der Visual Studio 6.

Doch einen Abschluss hat zum Glück erreicht, intern, dass unsere Produkt suchen etwas antiquiert im Vergleich zu unseren Konkurrenten ist, und dass etwas getan werden muss.

Ich arbeite derzeit an einem neuen Bereich in der Benutzeroberfläche, die ganz getrennt von dem rest des Produkts.Ich habe daher die chance gegeben, zu versuchen, "neue" Technologie-stacks, der als eine Art Testgelände vor den langen Prozess, der sich über den rest des UI beginnt.

Ich habe mit C# mit Windows Forms und die .net framework für eine Weile in meiner Freizeit und genießen es, aber ich bin etwas besorgt über die Kopfschmerzen, die durch interop.Während dieser besonderen Zweig der UI nicht benötigen viel interop mit der legacy-C++ - codebase kann ich forsee das immer ein Problem in die Zukunft.

Die alternative ist, nur um weiterhin mit MFC, aber versuchen Sie es und nutzen Sie das neue feature pack, das im Lieferumfang mit VS2008.Dies ist wohl die einfachste option, aber ich mache mir sorgen über die Langlebigkeit und die nicht unter Ausnutzung der Güte, die ist .net...

Also, was tun ich wählen?Wir sind ein kleines team, so dass meine Empfehlung sehr wahrscheinlich angenommen werden, wie eine zukünftige Richtung für unsere Entwicklung ist - ich möchte es richtig machen.

Ist, MFC-tot?C#/Winforms-der Weg in die Zukunft?Gibt es etwas, was ich Total vermisst?Hilfe sehr geschätzt!

War es hilfreich?

Lösung

Ich bin ein Entwickler auf eine app, die hat eine Tonne von legacy MFC-code, und wir haben Sie alle Ihre sorgen.Ein großer Treiber für unsere Strategie war es, bei minimalem Risiko und Unsicherheit, wie wir konnten, was bedeutete, dass Die Vermeidung der Groß schreiben.Wie wir alle wissen, TBR scheitert die meisten der Zeit.So entschieden wir uns für eine inkrementelle Ansatz, der es uns ermöglicht, zu bewahren Module, die nicht verändert werden, die in der aktuellen Version, neue Funktionen schreiben, verwaltet, andporting Funktionen sind Erweiterungen verwaltet.

Sie können dies tun, gibt es mehrere Möglichkeiten:

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

  2. Für MFC-MDI-apps, erstellen Sie eine neue WinForms-framework-und host-MFC-MDI-Ansichten (siehe hier)

  3. Host WinForms-user controls MFC-Dialoge und Ansichten (siehe hier)

Das problem mit der Annahme von WPF (option 1) ist, dass es erfordert, dass Sie umschreiben, dass alle UI-Elemente auf einmal, sonst es sehen ziemlich schizophren.

Der zweite Ansatz sieht lebensfähigen, aber sehr kompliziert.

Der Dritte Ansatz ist der, den wir ausgewählt haben, und er arbeitet sehr gut.Es ermöglicht das selektive aktualisieren Bereichen der app, während die Aufrechterhaltung der Kohärenz und sich nicht berühren, Dinge, die nicht gebrochen.

Die Visual C++ 2008 Feature Pack sieht interessant aus, ich habe nicht gespielt mit ihm, obwohl.Scheint, wie es könnte helfen, mit Ihrem Problem der veralteten look.Wenn das "Band" wäre zu hinderlich für Ihre Benutzer Sie ansehen konnte, third-party-MFC und/oder WinForms-Steuerelement Lieferanten.

Meine Allgemeine Empfehlung ist, dass interop + inkrementelle änderung ist definitiv vorzuziehen, die zu weitreichenden änderungen.

Nach der Lektüre Ihrer follow-up, ich kann definitiv bestätigen, dass die Produktivität des Frameworks erheblich überwiegen die Investition in das lernen mit it.Niemand in unserem team hatte C# verwendet am Anfang dieser Bemühungen, und jetzt haben wir alle es vorziehen.

Andere Tipps

Abhängig von der Anwendung und die Bereitschaft Ihrer Kunden zu installieren .NET (nicht alle von Ihnen sind), würde ich auf jeden Fall zu WinForms oder WPF.Interop mit C++ - code wird enorm vereinfacht, indem die Umgestaltung von nicht-UI-code in Klassenbibliotheken mithilfe von C++/CLI (wie Sie bemerkt haben, die in Ihre Auswahl von tags).

Das einzige Problem mit WPF ist, dass es schwer sein kann zu halten die aktuellen look-and-feel.Umzug in WinForms kann getan werden, während die Aufrechterhaltung der aktuellen Aussehen Ihrer GUI.WPF verwendet ein anderes Modell, das zu versuchen, das aktuelle layout, wäre wahrscheinlich sinnlos und würde auf jeden Fall nicht in den Geist der WPF.WPF auch anscheinend hat schlechte Leistung auf pre-Vista-Maschinen, wenn mehr als eine WPF-Prozess ausgeführt wird.

Mein Vorschlag ist, finden Sie heraus, was Ihre Kunden verwenden.Wenn die meisten bewegt haben, Vista und Ihrem team ist bereit zu setzen in eine Menge von GUI-Arbeit, würde ich sagen, überspringen WinForms und bewegen zu WPF.Ansonsten, auf jeden Fall ernst Blick auf WinForms.In jedem Fall wird eine Klassenbibliothek in C++/CLI ist die Antwort auf Ihre interop Bedenken.

Sie geben nicht viele Details über das, was Sie mit Ihren legacy-code enthält oder wie Sie aufgebaut ist.Wenn Sie bestimmte Leistungskriterien möchten Sie vielleicht zu halten, einige Ihrer Codebasis in C++.Sie ' ll haben eine einfacher Zeit-interop mit Ihrem alten code, wenn es ist ausgesetzt auf die richtige Weise - können Sie einen Anruf in die bestehende Codebasis von C# heute?Könnte sich lohnen, darüber nachzudenken einem Projekt, um diese Struktur Recht.

Auf den Punkt, WPF, könnte man argumentieren, dass WinForms besser geeignet sein können.Umzug in WinForms ist ein großer Schritt für Sie und Ihr team.Vielleicht haben Sie möglicherweise mehr komfortable mit dem Umzug in WinForms?Es ist besser dokumentiert, mehr Erfahrung in die Markt, und nützlich, wenn Sie benötigen noch die Unterstützung von windows 2000-clients.

Sie von Interesse sein könnten Erweitern MFC-Anwendungen mit dem .NET Framework

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

Ich danke Ihnen allen herzlich für Ihre Antworten, es ist beruhigend zu sehen, dass im Allgemeinen der Konsens folgt meiner Linie des Denkens.Ich bin in der glücklichen situation, dass unsere software läuft auch auf unserer eigenen hardware (für die broadcast-Industrie) - also die Wahl des OS ist wirklich unsere und Druck auf unsere Kunden.Derzeit betreiben wir XP/2000, aber ich kann sehen, ein Wunsch, sich zu bewegen bis zu Vista bald.

Jedoch, wir auch halten müssen, um sehr feine Kontrolle über die GPU-performance, ich glaube, das automatisch Regeln, WPF-und hardware-Beschleunigung?Ich hätte diesen Punkt in meinem ursprünglichen post - sorry.Vielleicht ist es möglich, zwei GPUs...aber das ist eine andere Frage, die zusammen...

Das team hat keine wesentlichen C# - Erfahrung und ich bin kein Experte, mir selbst, aber ich denke, die Allgemeine langfristige Vorteile einer verwalteten Umgebung wahrscheinlich überwiegen die Zeit es dauert, um bis zu Geschwindigkeit.

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

Waren Sie zu suchen bei der Umstellung auf C#, und daher .NET, ich würde Windows Presentation Foundation eher als WinForms.WPF ist die Zukunft des smart clients .NET, und die Fähigkeiten, die Sie abholen, werden Sie wiederverwenden können, wenn Sie möchten, um browser-gehosteten Silverlight-Anwendungen.

Ich schließe mit der WPF-Stimmung.Tag - /XML-basierten Benutzeroberfläche würde zu sein scheinen ein bisschen mehr tragbar als WinForms.

Ich denke, auch Sie haben zu prüfen, Ihr team, wenn es gibt nicht viele aktuelle C# - Fähigkeiten, dann ist das ein Faktor, sondern gehen nach vorne, den Markt für die MFC-Entwickler ist rückläufig und C# wächst.

Vielleicht eine Art fragmentarische Ansatz möglich wäre?Ich habe gewesen beteiligt mit Umkodierung von legacy-Anwendungen in C# ein bisschen, und es dauert immer viel länger, als würden Sie schätzen, vor allem, wenn Sie halten einige legacy-code, oder Ihr team ist nicht, dass vertraut mit C#.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top