3

C++/Powerbuilder で記述されたレガシー アプリケーションを C# に移植する機会があります。このスプリントには、独立したダイアログを起動する機能があり、C++ から呼び出されるこの機能のマネージ実装用の CCW dll を作成する演習を行いました。マネージ DLL のビューに WPF を使用することにしました。これまでのところ、サンプル MFC アプリから WPF ウィンドウを起動するなど、マネージ DLl と相互運用できるので、とても良いです。

この戦略を推進する理由はいくつかあります。

  1. 10 年前のレガシ アプリの最近の再設計から生まれた、再利用可能な管理 DLL がたくさんあります。
  2. 私は C++ と比較して C# でかなりの経験を積んでおり、C++ では常に言語の構文とインテリセンスと戦っています。FWIW、私たちの会社はいくつかのツールに投資することでもっとうまくいくかもしれませんが、C++構文、ヘッダーファイル、およびアプローチの不一致に対する私の嫌悪感を実際に変えることはありません.
  3. 少なくとも私たちが開発する種類のアプリケーション用のデスクトップ アプリについては、C# が適していると思います。4.アプリを書き直す将来の計画があり、繰り返したくありません。したがって、この段階で、できる限り正しい設計を開始したいという誘惑にかられます。
  4. C++ のヘルプはあまりありません。

ただし、いくつかの懸念と質問があります。

  1. この断片的なアプローチは進むべき道ですか?

  2. パフォーマンスの観点からは、WPF ではなく Winforms と相互運用する必要がありますか? アプリケーションは GIS をホストするため、パフォーマンスが重要ですが、ThinkGeo の MapSuite をホストする別の WPF アプリケーションを開発したばかりで、非常にうまく機能します。主な違いは、レガシ アプリが WPF の従兄弟よりも GIS を多用することです。

  3. WPF/Silverlight の運命についての最近の噂では、WPF を検討する必要がありますか? WPF/Silverlight が死んだ場合、デスクトップ アプリの代替手段は何ですか?

3.私を待っている落とし穴は何ですか?

これに関する考えやアドバイスは素晴らしいものです。これについてマネージャーと相談しますが、最初にあなたの考えや経験を聞きたいと思いました. ティア。

クラウス

編集：

申し訳ありませんが、アプリケーションは 10 歳であり、最初に述べた 25 歳ではありません。そこに少し混乱します。

4

1 に答える 1

1

断片的なアプローチよりも優れたアプローチは見当たりません。また、C++/CLI (別名マネージド C++) をいつでも使用して、困難なギャップを埋めることができます。

私は WPF/Silverlight の大ファンなので、Winforms よりも上にあることを強くお勧めします。Winforms は優れていますが、かなり古い技術です。カスタム コントロールとデータ バインディングにより、WPF の世界での長期的な開発が大幅に容易になりました。

WPF が消滅するという噂はまったくナンセンスです。はい、Microsoft は WPF チームの規模を縮小しました。主な理由は、WPF が成熟し、安定したためです。彼らは、戦略的な理由から、ブラウザー領域により多くのリソースを投入したいと考えています。なぜ誰かがそれをWPFを殺すことと同一視するのかわかりません。

C++ で記述されたレガシー コードのラッパーまたはインターフェイスとして WPF を使用することに大きな成功を収めました。私が遭遇した主な「落とし穴」は、マネージド コードとアンマネージド コードのレイヤーがある場合、少しトリッキーになり、デバッグが難しくなる可能性があるということです。カスタム アセンブリ ローダー コールバックを記述することを検討して、読み込みに失敗したものとその理由を詳しく確認することをお勧めします。特に、最終的にマネージ コードを実行する C++ DLL を読み込むレガシ アプリがある場合はそうです。

于 2011-07-05T18:39:25.200 に答える