1

ええと、私はプロジェクトを持っています.EF 5.0はWindows 7以降専用であるため、このアプリケーションはWindows XPと互換性があるため、.NET 4.0を使用しています。

ただし、EF 5.0 などの .NET 4.5 の機能を使用して、アプリケーションの一部を実装したいと考えています。

したがって、私のデータベース アクセスには、現在 EF 4.0 を使用するリポジトリ クラスがあります。これは独立した dll であるため、EF 5 を使用する他のリポジトリ dll を作成し、プロジェクトで両方の dll をインポートすると、正しいリポジトリをインスタンス化できます。私が使用できるEF 5.0のバージョンに。これは構成ファイルのパラメーターです。これが最善の方法ですか？

インターフェイスを宣言する必要がある場所がわからないため、これを尋ねます。私のリポジトリ クラスはこのインターフェイスを実装する必要がありますが、これにより dll がアプリケーションに結び付けられますが、このリポジトリを 2 つの異なるアプリケーションで使用する必要があるため、一度実装して多くのアプリケーションで使用したいと考えています。独立した dll が必要です。現在は 2 つのアプリケーションですが、将来的にはさらに多くのアプリケーションになる可能性があります。

リポジトリを使用するアプリケーションでインターフェイスを使用する理由は、構成ファイルの設定に従って、実行時に正しいリポジトリをインスタンス化したいからです。したがって、将来的には新しいリポジトリを実装でき、コードを変更する必要はありません。

EDIT1: マルチ ターゲティングについて読みましたが、プロジェクトで .NET 4.0 などの機能を使用していて、3.5 に準拠したい場合、この機能は 3.5 に存在しないため、エラーが発生します。そのとおりです。それでは、2 つの異なるプロジェクトを管理するしか方法はありませんか? 二重の作業になります。

ありがとう。ダイムロック。

4

1 に答える 1

1

したがって、私のデータベース アクセスには、現在 EF 4.0 を使用するリポジトリ クラスがあります。これは独立した dll であるため、EF 5 を使用する他のリポジトリ dll を作成し、プロジェクトで両方の dll をインポートすると、正しいリポジトリをインスタンス化できます。私が使用できるEF 5.0のバージョンに。これは構成ファイルのパラメーターです。これが最善の方法ですか？

あなたはこのルートに行くことができます。これが将来のメンテナンス/開発の頭痛の種になると思わない限り、実際には問題はありません。他にもいくつか検討できることがあります。どちらも完全に有効であり、おそらく個人的な意見/好みにすぎないと思います。

  1. モジュールリポジトリ DLL が潜在的に動的にロードされるモジュラー ルートに進むことができます。Microsoft の Unity ライブラリを調べてください。これにより、必要に応じてアプリケーションをセットアップする各リポジトリ DLL に IModule を作成できるようになります。次に、UnityBootstrapper クラスを作成して、モジュールを見つける方法 (手動でモジュールを追加する、ディレクトリを調べるなど) を伝えます。これにより、リポジトリ DLL をホット スワップできるようになり、不要な場合は構成ファイルの設定について心配する必要がなくなります。
  2. プリプロセッサ ディレクティブプリプロセッサ ディレクティブを使用すると、コードのコンパイル方法を定義できます。クラスをどのように構造化するかによって、これはかなり簡単に設定できる場合もあれば、クラスを抽象化してリファクタリングしたくなる完全な悪夢になる場合もあります。この質問:コンパイル時にターゲット フレームワークのバージョンを検出するには、ターゲット フレームワークに応じて異なるコンパイル結果を処理するための回答があります。個人的にはモジュラールートが好きです。

インターフェイスを宣言する必要がある場所がわからないため、これを尋ねます。私のリポジトリ クラスはこのインターフェイスを実装する必要がありますが、これにより dll がアプリケーションに結び付けられますが、このリポジトリを 2 つの異なるアプリケーションで使用する必要があるため、一度実装して多くのアプリケーションで使用したいと考えています。独立した dll が必要です。現在は 2 つのアプリケーションですが、将来的にはさらに多くのアプリケーションになる可能性があります。

リポジトリを使用するアプリケーションでインターフェイスを使用する理由は、構成ファイルの設定に従って、実行時に正しいリポジトリをインスタンス化したいからです。したがって、将来的には新しいリポジトリを実装でき、コードを変更する必要はありません。

UI とリポジトリ ライブラリ間の通信に使用する別のライブラリを作成する必要があるようです。これを適切に設定するには、少しトリッキーで圧倒される可能性があります。基本的に、ゲートウェイ DLL にインターフェイスとビジネス オブジェクトを格納する必要があります。アプリケーションはこの DLL を参照し、この DLL はリポジトリを参照します。

必要に応じて、インターフェイスと最も基本的なユーティリティ クラスを格納するだけの別の中間 DLL を実際にセットアップする必要がある場合があります。これにより、ゲートウェイ DLL がビジネス オブジェクトと EF オブジェクトを相互にマップしなくても、アプリケーションが使用しているのと同じインターフェイスを EF オブジェクトに実装できます。

EDIT1: マルチ ターゲティングについて読みましたが、プロジェクトで .NET 4.0 などの機能を使用していて、3.5 に準拠したい場合、この機能は 3.5 に存在しないため、エラーが発生します。そのとおりです。それでは、2 つの異なるプロジェクトを維持するしか方法はありませんか? 二重の作業になります。

上記のプリプロセッサ ディレクティブを使用することで、これを回避できると思います。以下は、フレームワークが .NET 2.0 であるかどうかに応じてメソッド ハンドルの動作が異なる例です。これは単なる例であり、テストされていません。DefineConstants を設定する必要がありますが、これにより、リリースされた新しい .NET 機能を使用しながら、複数のフレームワーク ターゲットに対して 1 つのプロジェクトを処理できるようになります。

public Person FindPersonByName(List<Person> people, string name)
{
#if DOTNET_20
    foreach(Person person in people)
    {
        if (person.Name == name)
            return person;
    }
    return null;
#else
    return people.FirstOrDefault(p => p.Name == name);
#endif
}

これが役に立ち、正しい解決策を見つける上で幸運を祈っています。

于 2012-11-10T12:30:16.173 に答える