たとえば、crud.dll を参照する Windows フォームを作成したいと考えています。次に、crud.dll を外部 dll として使用します。アイデアは、(データベースに接続する)crud.dllには多くのバージョンがあります(たとえば、Sybaseバージョン、SQLiteバージョン、異なるデータベースの詳細のための異なるバージョン)。私の場合、crud.dll は、using Sybase.Data.AseClient;
Sybase.AdoNet2.AseClient.dll も別の dll に依存しているため、ビルドするとエラーが発生しました。物事を正しく行うには?お時間をいただきありがとうございます。
2 に答える
アプリケーション ロジックからデータベース アクセス コードを抽象化する必要があります。データベース操作をアプリケーション ロジックから分離するために、依存性注入と組み合わせてリポジトリ パターンを使用できます。
アプリケーションは参照先の DLL を静的にリンクするため、DLLごとに個別の Windows フォーム アプリケーションをコンパイルする必要があります。明らかに望ましいアプローチではありません。別の方法として、動的読み込み ( LoadLibrary、GetProcAddress ) を使用することもできますが、これはエラーが発生しやすく、適切なcrud.dllを見つけるのが難しいため、 DLL-Hellにつながります。
より良い代替手段は、アプリケーションでサポートされているすべてのプロバイダーを静的に型付けすることです (たとえば、典型的なリポジトリ パターンの実装はこのカテゴリに分類されます)。これにより、これらすべての問題が解消されますが、サポートされるプロバイダーのセットは、アプリケーションのコンパイル時にハードワイヤードされます。
最新の代替手段は、crud.dll によって提供されるサービスを COM 経由で公開し、アプリケーションで目的の COM クラス (プロバイダー実装の 1 つによってサポートされる) を構成することです。
最終的にプロバイダーを*動的に*ロードし、ビルド時にサポートされているプロバイダーのリストを静的に固定しないことは困難です。要件を真剣に再検討し、よく知られているサポートされているプロバイダーのセットをコンパイル時に修正するかどうかを検討し、利用可能な多くの静的にリンクされたアプローチ (リポジトリ パターンなど) のいずれかを使用します。