2

OracleのProCプリコンパイラライブラリ（proc.exe）を使用して100個ほどのsproc /func呼び出しをさらに古いVB6GUIに公開する古いC32ビットDLLがいくつかあります。これは、次のような明示的なDeclareステートメントを通じてこれらの関数を参照します。

Declare Function ConnectToDB Lib "C:\windows\system32\EXTRACT32.DLL" (CXN As CXNdets, ERR As ERRdets) As Long

Cヘッダーファイルのすべての構造は、VB6フロントエンドで入念に複製されます。少なくともSQLはプリコンパイルされています。

私の質問は、.Netインターフェイスを（アセンブリに変換して）Cコードに適用してVB6をC＃にアップグレードする価値があるのか​​、それともすべてを放棄して最初からやり直すべきだと思いますか。いつものように、時間が重要であるため、以前の経験に対する私の魅力です。宣言を.Netに保持する場合、避けたい複雑なマーシャリング装飾をたくさん追加する必要があることを私は知っています。

私はこれまでCを.Netに変換する必要がなかったので、他のすべてが無視された場合の私の主な質問は、これをお勧めできない移植の制限はありますか？

4

4 に答える 4

3

...少なくともSQLはプリコンパイルされています。

これがCでコードを持っている唯一の理由ですか？もしそうなら、私のアドバイスはそれを放棄し、C＃ですべてを書き直すことです（またはそれがあなたのアプリが書かれているものであればVB6でさえ）...あなたがそれをプロファイリングして測定可能な違いを証明できない限り、あなたはしませんCでsql/sproc呼び出しを行うことで、パフォーマンスのメリットが得られます。この相互運用ブリッジの保守が複雑になるため、保守コストが増加するだけです。

于 2009-11-17T13:42:59.683 に答える
2

宣言の周りにアセンブリを作成して、.NETでDLLを引き続き使用する必要があります。その1つのアセンブリは、おそらくVB.NETではC＃よりも少し速くなります。次に、新しいUIでそのアセンブリを参照します。それができたら、Cコードを.NETに変換する時間を自分で購入しました。これを行うには、最初にアセンブリを保持し、宣言を新しい.NETコードに置き換えます。すぐにすべてを置き換えて、別のデザインにリファクタリングできます。

タイムキラーは行動を壊しています。元のアプリケーションの動作を維持できるほど、変換は速くなります。従来のDLLを参照することに何の問題もないことを忘れないでください。.NETはAPIの多くのレイヤー上に構築されており、最終的にはWindowsで引き続き使用される従来のDLLにドリルダウンします。繰り返しますが、.NET UIが機能するようになると、コアで作業し、すべてを.NETに取り込むための時間が増えます。

于 2009-11-17T16:01:46.790 に答える
1

何かを書き直す前に、常に細心の注意を払うことをお勧めします。適切なツールを使用してVB6を.NETにアップグレードすると、Declareステートメントが自動的に変換されるため、あまりストレスをかけないでください。

大きなソフトウェアを楽観的に書き直し、古いアーキテクチャのよく知られた欠陥のいくつかを修正することから始めて、それからあなたが今当然と思っていた機能に行き詰まるのはよくある落とし穴です。年。この時点で、あなたの経営陣はけいれんし始め、すべてが非常に不快になる可能性があります。私はそこに行ったことがあり、それは楽しいことではありません。あなたのユーザーはすでにけいれんしているように聞こえますが、これは悪い兆候です。

...そしてこれが私に同意するMicrosoftによるブログ投稿です：

私が.NETの初期に協力していた多くの企業は、.NETに移行すると同時に、基盤となるアーキテクチャとコード構造を改善したいという強い願望に一部駆り立てられて、最初に書き換えを検討しました。残念ながら、これらのプロジェクトの多くは困難に直面し、いくつかは完了しませんでした。彼らが解決しようとしていた問題は大きすぎました

...およびVB6から.NETへの移行に関するMicrosoftUKからの公式アドバイス

.NETへの完全な書き換えを実行することは、[変換するよりも]はるかにコストがかかり、うまく実行するのが困難です...少数の状況でのみこのアプローチをお勧めします。

たぶんあなたのプログラムは小さく、あなたはそれが解決する問題をよく理解していて、あなたは正確に見積もり、あなたのプロジェクトを軌道に乗せることに長けています、そしてそれはすべてうまくいくでしょう。

于 2009-11-17T17:40:30.410 に答える
1

VB6からVB.netまたはC＃に移動する場合は、Cコードを破棄し、適切なODP.netクラスまたはLINQを使用してこれらのストアドプロシージャにアクセスします。Cレイヤー（私が理解しているように）にはストアドプロシージャを公開する以外のロジックがないため、切り替え後はもう役に立ちません。そうすることで、（少なくとも）はるかに優れた例外処理（つまり、魔法の戻りコードの代わりに例外を処理する）、保守性などが得られます。

参照：ストアドプロシージャの周りにC＃ラッパークラスを自動的に作成する

于 2009-11-18T13:19:05.390 に答える