2013-01-16 3 views
5

Ich weiß, es gibt eine Menge Qt vs MFC Fragen, aber ich werde versuchen, sehr spezifisch zu sein.Wird die Verwendung von Qt in einer großen MFC Windows-Only-App die Entwicklung beschleunigen?

Wir haben eine große (10 Jahre Entwicklung) C++ MFC-Anwendung für Nischenindustrie. Es soll Windows-only bleiben und nur für immer englisch. Aber wir müssen eine Menge neuer Designer-GUIs und GUI-Steuerelemente (Dialoge, Schaltflächen, benutzerdefinierte Listen, ...) hinzufügen.

Wir können 1 oder 2 neue GUI-Entwickler einstellen, um diese neuen Schnittstellen zu erstellen, so dass wir es uns leisten können, andere Technologien als MFC zu wählen.

Qt scheint am vielversprechendsten und geeignet zu sein, Seite an Seite mit MFC zu laufen (oh, nein, wir reduzieren die App nicht von Grund auf neu).

Es scheint, dass die meisten zitierten Qt-Vorteile irrelevant sind: plattformübergreifende Entwicklung, einfache Internationalisierung, OpenSource, Bibliotheken ohne GUI (wir brauchen keine Vernetzung und haben die meisten anderen Funktionen bereits implementiert).

Aber Qt ist auch berühmt für sein gutes OO Design und sie haben QtQuick kürzlich eingeführt. Ich möchte ihm eine Chance geben, so dass die Fragen sind

  • In einem kommerziellen reinen Windows-Projekt, was substantional Vorteile von aus den reinen MFC MFC + Qt zu bewegen, die die Mühe wert sind Qt zu lernen, es in unseren Build/Deploy-Prozess zu integrieren und vielleicht für eine kommerzielle Lizenz zu bezahlen?
  • Insbesondere, wird es die Entwicklung beschleunigen, wenn wir neue GUIs in Qt bauen und sie in die App über QWinWidget integrieren?
+0

Ich wäre neugierig zu wissen, wie Sie MFC und Qt zusammen laufen, hätte ich es für unmöglich gehalten - es kann nur eine Nachrichtenschleife sein. –

+2

Alle meine Spinne Sinne sagen mir, dass dies eine schlechte Idee ist, ist es fast garantiert, dass Sie mehr Aufwand als es wert ist, einen konsistenten Zustand zwischen MFC und QT zu halten. – Ylisar

+1

@MarkRansom, http://doc.qt.digia.com/solutions/qtwinmigrate/index.html – Steed

Antwort

3

Wahrscheinlich nicht.

Wenn die gui und Geschäftslogik schön getrennt sind dann könnte es sinnvoll, die gui allmählich auf Qt zu verschieben oder neue Teile in Qt implementieren - aber wir wissen beide, dass die gui/Logik wird

eine schreckliche gemischt zusammen Einander

Wenn Sie eine Neuschreibung durchführen (was der Qt am Ende sein wird), dann ist es wahrscheinlich einfacher, C#/.net zu verwenden, wenn es sich um eine normale Geschäftstyp-App handelt.

Wenn die Leistung ist entscheidend, und Sie haben eine Menge von Domain-Wissen in gut definierten gut getrennt C++ Libs dann ein Qt Frontend würde sich lohnen gebunden

+0

Danke, Martin. Ja, die Leistung ist entscheidend und die Codebasis ist riesig, und, ja, wir haben eine schlechte GUI/Logik-Trennung. .NET war unsere erste Idee, aber selbst das Kompilieren der App mit C++/CLI wäre ein Problem, ganz zu schweigen von dem Umschreiben in C#. – Steed

0

nicht grundsätzlich auf eine Frage antworten, aber vielleicht als weel hilfreich sein . Ich denke, eine andere Möglichkeit, GUI mit neueren Tools zu machen, ist die Verwendung von ActiveX und COM. Ich glaube, dass Sie ActiveX-Komponenten in Ihren MFC-Anwendungen problemlos verwenden können. Außerdem gibt es viele Möglichkeiten, solche Steuerelemente zu erstellen. Ich benutzte Delphi, um Steuerelemente zu verwenden, die erfolgreich in .NET WinForms-Anwendungen verwendet wurden, aber soweit ich weiß, können solche Steuerelemente in .NET-Umgebung mit wenig Aufwand erstellt werden.

Verwandte Themen