将来の大規模なUIアプリケーションの校正 - 2008年のFeature Pack、またはC＃とWinformsのMFC？

Question

私の会社は、UI開発のデファクトスタンダードとして、Visual C++のMFCを使用して長年の製品を開発しています。私たちのコードベースには、操作性を保つ必要のあるレガシー/古典コードがたくさん含まれています。このコードの一部は私より古いです（当初は70年代後半に書かれていました）。私たちのチームの一部のメンバーはまだVisual Studio 6です。私たちの競合相手に、そして何かをする必要があるということです。

私は現在、UIの新しい領域に取り組んでいます。これは、他の製品とはまったく別物です。したがって、私は、UIの残りの部分を動かすという長いプロセスが始まる前に、ある種の証明地として「新しい」テクノロジースタックを試してみる機会が与えられました。

私はWindows Formsと.netフレームワークでC＃を使っていましたが、私の暇な時間にはしばらくの間楽しんでいましたが、相互運用性によって引き起こされる頭痛にいくらか心配しています。 UIのこの特定のブランチは、レガシーC++コードベースとの相互運用性をあまり必要としませんが、将来的にはこれが問題になることは考えられます。

代わりに、MFCを続行するだけですが、VS2008に同梱されている新しいフィーチャーパックを試してみてください。これは私が推測する最も簡単なオプションですが、私は長寿について心配し、その良さを利用していません...

だから私は選ぶのですか？私たちは小規模なチームですので、私の推薦は私たちの開発の将来の方向性として受け入れられるでしょう - 私はそれを正しくしたいと思います。

MFCは死んでいますか？ C＃/ Winformsは進歩していますか？私が完全に欠けていることは何ですか？ヘルプは非常に感謝！

Answer 1

私は大量の従来のMFCコードを持つアプリの開発者です。私たちは皆さんの懸念をすべて抱いています。私たちの戦略の大きな原動力は、可能な限り多くのリスクと不確実性を排除することでした。これは、The Big Rewriteを回避することを意味しました。私たち皆が知っているように、TBRはほとんどの場合失敗します。そこで、現在のリリースでは変更されないモジュールを保存し、管理されている新しい機能を記述し、機能拡張を管理する機能を移植するインクリメンタルな方法を選択しました。新しいWinFormsのフレームワークを作成し、あなたのMFCビュー（hereを参照）MFC MDIアプリケーションの場合

に

1. ホストWPFコンテンツを、あなたMFC MDIビューをホスト：

   あなたはこのいくつかの方法を行うことができますMFCダイアログとビューで

2. ホストのWinFormsユーザーコントロール（hereを参照）

（ hereを参照してください）

WPF（オプション1）を採用する際の問題は、すべてのUIを一度に書き換える必要があることです。それ以外の場合は、かなり統合失調症に見えます。

第2のアプローチは実行可能だが非常に複雑です。

3番目のアプローチは、私たちが選んだアプローチであり、非常にうまくいっています。全体的な一貫性を維持しながら、アプリケーションの領域を選択的に更新し、壊れていないものには触れないようにすることができます。

Visual C++ 2008 Feature Packは興味深いように見えますが、私はそれをやっていません。あなたの古い外観の問題に役立つかもしれないようです。 "リボン"があなたのユーザーにとってあまりにも不快ならば、サードパーティのMFCおよび/またはWinFormsコントロールベンダーを見ることができます。

私の全体的なお勧めは、interop +インクリメンタル変更は、変更を一掃することよりもはるかに望ましいことです。

---

はあなたのフォローアップを読んだ後、私は間違いなく、フレームワークの生産性の向上が大幅にそれを学習に投資を上回ることを確認することができます。私たちのチームの誰もこの作業の開始時にC＃を使用していたわけではありません。

Answer 2

C＃と.NETへの移行を見ていたら、WinFormsではなくWindows Presentation Foundationを検討します。 WPFは.NETのスマートクライアントの未来であり、あなたが拾ったスキルは、ブラウザでホストされたSilverlightアプリケーションを作成する場合に再利用できるようになります。

Answer 3

私はWPFの意見に同意します。タグ/ XMLベースのUIは、WinFormsよりも移植性があるようです。

現在のC＃スキルがあまりない場合は、チームを考慮する必要があります。それが要因ですが、MFC開発者の市場は縮小し、C＃は成長しています。

多分いくつかの種類のアプローチが可能でしょうか？私はC＃へのレガシーアプリケーションのレコーディングにかなり関わってきました。特に、レガシーコードを保管している場合や、チームがC＃に精通していない場合は、予測よりも時間がかかります。

Answer 4

アプリケーションと.NETをインストールする顧客の意欲（すべてではない）によって、私は間違いなくWinFormsまたはWPFに移行します。 Interop with C++コードは、UI以外のコードをC++/CLIを使用してクラスライブラリにリファクタリングすることで大幅に簡素化されています。

WPFの唯一の問題は、現在のルックアンドフィールを維持するのが難しいことです。 WinFormsへの移行は、GUIの現在の外観を維持しながら行うことができます。 WPFは、現在のレイアウトを維持しようとすると、おそらく無駄になり、WPFの精神にはならないような異なるモデルを使用します。 WPFは、複数のWPFプロセスが実行されている場合でも、Vista以前のマシンではパフォーマンスが低下しているようです。

あなたのクライアントが使用しているものを見つけることです。ほとんどの人がVistaに移行して、あなたのチームが多くのGUI作業を行う準備が整ったら、私はWinFormsをスキップしてWPFに移行すると言うでしょう。さもなければ、間違いなくWinFormsを真剣に見てください。どちらの場合でも、C++/CLIのクラスライブラリは相互運用性の問題に対する答えです。

Answer 5

あなたのレガシーコードが何をしているのか、それがどのように構造化されているかについて詳しくは分かりません。特定のパフォーマンス基準がある場合、C++でコードベースの一部を維持したいかもしれません。正しいコードで公開されていれば、古いコードとの相互運用が容易になります.-今日のC＃の既存のコードベースを呼び出すことはできますか？この構造を正しくするためのプロジェクトについて考えてみる価値があります。

WPFのポイントでは、WinFormsがより適切かもしれないと主張することができます。 WinFormsへの移行は、あなたとあなたのチームにとって大きなステップです。おそらく、WinFormsへの移行がより快適になるかもしれません。それは、市場でのより良い文書化、より多くの経験、およびWindows 2000クライアントをサポートする必要がある場合に便利です。あなたが考慮すべき他のExtending MFC Applications with the .NET Framework

何かに興味があるかもしれません

はC++/CLIですが、私はそれで経験を持っていません。

Answer 6

ご回答いただきありがとうございます。一般的にコンセンサスが私の考え方に沿っていることを確認することができます。私は幸いなことに、私たちのソフトウェアも独自のカスタムハードウェア（放送業界向け）で動作しているため、OSの選択は本当に私たちのものであり、お客様に押し付けられています。現在、私たちはXP/2000を実行していますが、すぐにVistaに移行したいという希望があります。

しかし、GPUのパフォーマンスを非常に細かく制御する必要もあります。これは自動的にWPFとハードウェアアクセラレーションを排除していると思いますか？私は元の投稿にその点を作っておかなければならなかった。おそらく2つのGPUを使用することは可能ですが、それはまったく別の質問です...

チームには重大なC＃の経験はなく、私は専門家ではありませんが、おそらく最速化するのにかかる時間を上回る可能性があります。

WinformsとC＃のように見えます。