VB6 レガシー アプリケーションを開発しています。私はすべての新しいコードを VB.NET で書き始め、基本的に相互運用レイヤーと呼んでいるものを作成しています。これには、次の 2 つの方法でアプローチできます。
私の質問は、どちらがより良いアプローチですか?
UPDATE 私がオプション 1 を支持する理由は、ASP.NET アプリケーションがあるからです。以前の開発者は、VB6 と ASP.NET の両方のアプリでコードを効果的に複製していました。したがって、ASP.NET アプリのコードの一部は VB6 と共有でき、その逆も可能です。そのため、オプション 1 の方が優れていると思いますが、開発者が実際にこれを行うことを示唆する文献を見つけることができません。
前世では、同じタイプのプロジェクトに携わっていました。元のアプリケーションは、Access をフレームワークとして使用して作成されました。その後、VB6 が登場しました。VB6 は、Access で最初に記述されたものを大幅に変更することなく、うまく機能し、より多くの機能を使用できるようになりました。
それに伴い、.Net ...
....Netへの開発ステージングが嫌いで、相互運用レイヤーで作業することを余儀なくされたのと同じくらい、それが必要でした。
とはいえ、私は可能な限り主観的に質問に答えます。
アプリケーションが完全に .Net に変換されることがわかっている場合は、できる限り多くの新しい開発を .Net で行ってください。相互運用性に関する認識 (および真実) 以外に、それを先延ばしにする理由はありません。たとえば、オーバーヘッドやパフォーマンスの増加などです。
サイドバー - 少なくとも、Access との相互運用性の問題はありません。クラッシュすると、すべてがダウンします。相互運用性 (Access を使用) は初めての経験でしたが、きれいではありませんでした。
.Net 開発を待つ利点:
.Net 開発を待つことの欠点:
今すぐ .Net 開発を開始すると、長期的に成功する可能性が高くなります。相互運用レイヤーが私にとっての頭痛の種になるとは思いません。また、パフォーマンスの低下は最小限に抑える必要があります。
あなたがこのプロジェクトの開発者チームに参加しているかどうかはわかりませんが、もしそうなら、全員が .Net への移行に参加していることを確認してください。数人の VB6 開発者が VB.Netでヘッドライトのポーズをとっているのを見たことがあります。性質は、彼らが慣れ親しんだのと同じスタイルで書き続けることです.
ユーザーが望むものを提供することに集中してください。vb6 でこれを実現する方が簡単な場合は、そうしてください。vb.net への変換が必要な場合は、vb.net への変換を心配します。vb6 を .net に変換するツールは現在かなり優れており、継続的に開発されているため、さらに改善されることが期待できます。
私は個人的にあなたの最初のオプションを使用します（相互運用性レイヤーが既に実装されているため）。そうすれば、クラス構造を正しく設計すれば、書き直しの負担が軽減されます。2 番目のオプションは私の好みの方法ですが、時間の制約があるため、最初のオプションを使用してください。最終的に、VB6 ランタイムは新しいバージョンの Windows の一部にはなりません。このSO の質問を参照してください。私自身、変換が必要な VB6 アプリケーションを持っています。