0

私たちが現在持っているのは、EntitySpaces を使用した比較的古いコードベースです (実際には問題ではありませんが、ORM であり、以前は使用するのに便利でしたが、最近の EntityFramework の経験では、それほど多くはありません)。データベースに直接アクセスするための ORM として。現在、EntitySpaces オブジェクトに直接依存しているアプリケーションの多くの部分を変更する必要に迫られています。これは良くありませんが、それが今のやり方です。私の一般的な考えは、ニュートラルで永続性を認識しないオブジェクトを導入するレイヤーを導入し、それらのオブジェクトを取得、更新などするためのある種のリポジトリ インターフェイスを作成し、EntitySpaces を引き続き使用する (最初の) 実装を作成することです。次に、現在 EntitySpaces を直接使用しているすべてのクラスとコンポーネントをリファクタリングできます。

ここに私の質問/不安があります：

一般的に、1 つのリポジトリ オブジェクトをどこかに置きたいですか、それとも (特定の) リポジトリを返すファクトリをコンポーネントに提供する方がよいでしょうか? たぶん、リポジトリをさまざまな種類のオブジェクトのさまざまなインターフェイスに分割することもできます。これにより、20程度のインターフェイスになると思います。

データベースで多くの操作を実行する UI コンポーネントがあるとします。リポジトリに対して動作するようにそれらを書き直す場合、それらのコンポーネントにリポジトリ オブジェクトを「与える」か、リポジトリがどこかにあることを知る必要さえない方法でこの UI コンポーネントを書き直す方がよいでしょうか? Partデータベースから をロードし、変更して送り返すことができるダイアログがあると想像してください。これは、ユーザーが [更新]または[削除]ボタンを押しPartEditorたときに使用するコールバックを指定できる、ある種のインターフェイスと見なすことができます。

このタスクに DI フレームワークを使用しますか? アプリケーションは比較的大きく、会社全体のライブラリを再利用することなく、約 800k loc だと思います。別の方法は、DI フレームワークを使用せずに、すべてのコンポーネントから具象クラスを非表示にして、新しい問題の発生を回避することです。私の新しい抽象化を使用するコンポーネントの場合、これらのコンポーネントは、使用されている DI フレームワークを知る必要がない方法で作成する必要があるため、違いはありません。

これは非常に抽象的で、答えるのが難しいかもしれませんが、他の人がこの種の作業を経験したことを願っています. ポインタに感謝します。どの DI フレームワークを使用するかについては、完全にオープンです。

4

2 に答える 2

1

一般的に、1 つのリポジトリ オブジェクトをどこかに置きたいですか、それとも (特定の) リポジトリを返すファクトリをコンポーネントに提供する方がよいでしょうか? たぶん、リポジトリをさまざまな種類のオブジェクトのさまざまなインターフェイスに分割することもできます。これにより、20程度のインターフェイスになると思います。

ドメインからデータへの変換を非表示にする汎用リポジトリを作成し (OR/M などを使用)、後で制御の反転を使用してインスタンス化することをお勧めします。

// The factory hides who's the actual 
// repository implementation. In your case, it could be 
// EntityFrameworkRepository<T> or EFGenericRepository<T>
GenericRepository<Order> orderRepo = RepositoryFactory.Create<Order>();

リポジトリには次のメソッドがある場合があります。

  • 追加。
  • GetById。
  • 削除する。
  • GetByCriteria([式ツリー]) (例: queryable => queryable.Where(...))。このメソッドは、入力引数を として受け入れる場合がありますExpression<Func<IQueryable<T>, IQueryable<T>>>。Entity Framework と NHibernate を使用すると、この方法で実装できます。

このアプローチ (汎用リポジトリ) を使用すると、20、30 のリポジトリを回避でき、さらに、コード ベース全体に特定の依存関係が広がるのを避けるために、OR/M 固有のタスクを実装するベース リポジトリの実装が得られます。

データベースで多くの操作を実行する UI コンポーネントがあるとします。リポジトリに対して動作するようにそれらを書き直す場合、それらのコンポーネントにリポジトリ オブジェクトを「与える」か、リポジトリがどこかにあることを知る必要さえない方法でこの UI コンポーネントを書き直す方が良いですか? データベースから部品をロードし、変更して送り返すことができるダイアログがあると想像してください。これは、ユーザーが [更新] または [削除] ボタンを押したときに使用するコールバックを与えることができる、ある種の PartEditor インターフェイスと見なすことができます。

UI はリポジトリについて認識すべきではありません。UI やリポジトリなどのメディエーターであるビジネス ドメインである必要があります。

このタスクに DI フレームワークを使用しますか? アプリケーションは比較的大きく、会社全体のライブラリを再利用することなく、約 800k loc だと思います。別の方法は、DI フレームワークを使用せずにすべてのコンポーネントから具体的なクラスを非表示にして、新しい問題の発生を回避することです。私の新しい抽象化を使用するコンポーネントの場合、これらのコンポーネントは、使用されている DI フレームワークを知る必要がない方法で作成する必要があるため、違いはありません。

はい、DI/IoC フレームワークを使用します。避けられないことを避けたり、車輪を再発明したりしないでください。これは、サードパーティのライブラリを使用するよりも大きな問題です。その成熟度、堅牢性、および機能豊富なフレームワークにより、Castle Windsorをお勧めします。

于 2013-02-12T10:31:31.603 に答える