5

QtとMFCの質問がたくさんあることは知っていますが、具体的に説明します。

ニッチ産業向けの大きな（10年の開発）C++MFCアプリケーションがあります。それは永遠にWindowsのみと英語のみにとどまることになっています。ただし、デザイナーが作成した新しいGUIとGUIコントロール（ダイアログ、ボタン、カスタムリストなど）を多数追加する必要があります。

これらの新しいインターフェイスを構築するために1人または2人の新しいGUI開発者を雇うことができるので、MFCとは異なるテクノロジーを選択する余裕があります。

Qtは、MFCと並行して実行するのに最も有望で適切なようです（ああ、いや、アプリを最初から作り直すわけではありません）。

クロスプラットフォーム開発、簡単な国際化、オープンソース、非GUIライブラリ（ネットワークは必要なく、他のほとんどの機能はすでに実装されています）など、引用されているQtの利点のほとんどは無関係のようです。

しかし、Qtはその優れたOOデザインでも有名であり、最近QtQuickを導入しました。チャンスを与えたいので、質問は

  • 商用のWindowsのみのプロジェクトでは、純粋なMFCからMFC + Qtに移行することの実質的な利点は何ですか。これは、Qtを学習し、ビルド/デプロイプロセスに統合し、商用ライセンスを購入するのに苦労する価値があります。
  • 特に、 Qtで新しいGUIを構築し、QWinWidgetを介してアプリに組み込むと、開発がスピードアップしますか？
4

2 に答える 2

3

おそらくそうではありません。

GUI とビジネス ロジックが適切に分離されている場合は、GUI を徐々に Qt に移行するか、Qt に新しい部分を実装することが理にかなっているかもしれませんが、GUI/ロジックが混ざり合ってひどい混乱になることはわかっています。

書き換えを行っている場合 (Qt の最終的な結果)、それが通常のビジネス タイプのアプリであれば、C#/.net を使用する方がおそらく簡単です。

パフォーマンスが重要で、適切に定義された適切に分離された C++ ライブラリに多くのドメイン知識が結び付けられている場合、Qt フロント エンドは価値があります。

于 2013-01-16T17:44:12.280 に答える
0

基本的に質問に答えるわけではありませんが、weelとして役立つかもしれません。新しいツールでGUIを実行する別の方法は、ActiveXとCOMを使用することだと思います。MFCアプリケーションでActiveXコンポーネントを簡単に使用できると思います。また、そのようなコントロールを作成する方法はたくさんあります。私はDelphiを使用して、.NET WinFormsアプリケーションで正常に使用されたコントロールを実行していましたが、私が知る限り、そのようなコントロールは.NET環境でほとんど労力をかけずに作成できます。

于 2013-01-16T18:55:36.717 に答える