12

私の会社は、Visual C++ の MFC を UI 開発のデファクト スタンダードとして使用する長年の製品を開発しました。私たちのコードベースには、運用を維持する必要があるレガシー/古風なコードが大量に含まれています。このコードの一部は私よりも古く (最初に書かれたのは 70 年代後半)、チームの一部のメンバーはまだ Visual Studio 6 を使用しています。

しかし、ありがたいことに、当社の製品は競合他社の製品と比較してやや時代遅れに見え、何かを行う必要があるという結論に達しました.

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

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

別の方法は、MFC をそのまま使用することですが、VS2008 に同梱されている新しい機能パックを利用してみてください。これが最も簡単なオプションだと思いますが、寿命が長く、.net の利点を活用できないことを心配しています...

それで、私はどれを選びますか？私たちは小さなチームなので、私の提案は将来の開発の方向性として受け入れられる可能性が非常に高いです - 私はそれを正しくしたい.

MFCは死んでいますか？C#/Winforms は進むべき道ですか? 私が完全に見逃しているものは他にありますか？大変助かります！

4

6 に答える 6

8

私は大量のレガシーMFCコードを含むアプリの開発者ですが、私たちはあなたと同じ懸念を抱いています。私たちの戦略の大きな推進力は、可能な限り多くのリスクと不確実性を排除することでした。これは、ビッグリライトを回避することを意味しました。ご存知のとおり、TBRはほとんどの場合失敗します。そのため、現在のリリースで変更されないモジュールを保持し、管理対象の新機能を作成し、管理対象の機能が強化されている機能を移植できるようにするインクリメンタルアプローチを選択しました。

これはいくつかの方法で実行できます。

  1. MFCビューでWPFコンテンツをホストします（ここを参照）

  2. MFC MDIアプリの場合は、新しいWinFormsフレームワークを作成し、MFC MDIビューをホストします（ここを参照） 。

  3. MFCダイアログとビューでWinFormsユーザーコントロールをホストします（ここを参照）

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

2番目のアプローチは実行可能に見えますが、非常に複雑です。

3番目のアプローチは、私たちが選択したアプローチであり、非常にうまく機能しています。全体的な一貫性を維持し、壊れていないものに触れずに、アプリの領域を選択的に更新できます。

Visual C ++ 2008 Feature Packは面白そうですが、私はまだ遊んでいません。古くなった外観の問題に役立つ可能性があるようです。「リボン」がユーザーにとって不快すぎる場合は、サードパーティのMFCやWinFormsコントロールベンダーを調べることができます。

私の全体的な推奨事項は、変更を一掃するよりも、相互運用+増分変更の方が確実に望ましいということです。

あなたのフォローアップを読んだ後、私はフレームワークの生産性の向上がそれを学ぶための投資をはるかに上回っていることをはっきりと確認することができます。私たちのチームの誰もこの取り組みの開始時にC＃を使用していませんでしたが、今では私たち全員がそれを好みます。

于 2008-08-14T13:32:29.810 に答える
2

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

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

チームには重要なC＃の経験がなく、私自身も専門家ではありませんが、管理された環境の全体的な長期的なメリットは、スピードを上げるのにかかる時間よりもおそらく大きいと思います。

WinformsとC＃には今のところそれがあるようです。

于 2008-08-14T13:30:47.177 に答える
2

アプリケーションと .NET をインストールする顧客の意欲 (全員がインストールしているわけではありません) に応じて、私は間違いなく WinForms または WPF に移行します。C++ コードとの相互運用性は、C++/CLI を使用して非 UI コードをクラス ライブラリにリファクタリングすることで大幅に簡素化されます (タグの選択で指摘したとおり)。

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

私の提案は、クライアントが何を使用しているかを調べることです。ほとんどが Vista に移行しており、チームが多くの GUI 作業を行う準備ができている場合は、WinForms をスキップして WPF に移行することをお勧めします。それ以外の場合は、WinForms を真剣に検討してください。どちらの場合でも、C++/CLI のクラス ライブラリは、相互運用に関する問題への答えです。

于 2008-08-14T11:40:53.373 に答える
2

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

WPF に関しては、WinForms の方が適切であると主張できます。WinForms への移行は、あなたとあなたのチームにとって大きな一歩です。おそらく、彼らは WinForms への移行に慣れているのではないでしょうか? 文書化されており、市場での経験が豊富で、まだ Windows 2000 クライアントをサポートする必要がある場合に役立ちます。

.NET Framework を使用した MFC アプリケーションの拡張に興味があるかもしれません

他に考慮すべきことはC++/CLIですが、経験がありません。

于 2008-08-14T12:04:56.460 に答える
1

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

于 2008-08-14T11:28:23.570 に答える
0

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

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

たぶん、ある種の断片的なアプローチが可能でしょうか？私はレガシー アプリケーションの C# への再コーディングにかなりの時間を費やしてきましたが、特にレガシー コードを保持している場合や、チームが C# にそれほど精通していない場合は、予想よりもはるかに長い時間がかかります。

于 2008-08-14T11:36:47.173 に答える