3

一番上の LLBLGen (アダプター) にリポジトリを構築するのは良い考えかどうか疑問に思っていました。私はオーバーエンジニアリングしたり、車輪を再発明したりしたくありません。DataAccessAdapter クラスは、ある種の汎用リポジトリである可能性があります。これには、必要な CRUD メソッドがすべて含まれています。

しかし、大規模なプロジェクトの場合は、ORM とサービス レイヤーの間にレイヤーを配置するとよいでしょう。

LLBLGen でリポジトリ パターンを使用している場合は、ご意見をお聞かせください。

実装がある場合は、投稿してください。

4

2 に答える 2

2

直接的なメリットは、特定のテクノロジーへのロックインを防ぎ、後で適切なテクノロジーを柔軟に選択できるようにすることです。

私見、もっと重要な理由は、ユビキタス言語を強制することです。アプリケーション/システムが進化するにつれて、複数の方法でデータをクエリする必要があります。リポジトリは、複雑なクエリをカプセル化するのに役立ちます。

一般的な実装では、コンシューマーコードは次のようになります。

customerRepo = ServiceLocator.Current.Resolve<IRepository<Customer>>();
var matchingCustomers = customerRepo.GetAll().Where(c => <some complex condition here>);

リポジトリを使用すると、次のようになります。

customerRepo = ServiceLocator.Current.Resolve<ICustomerRepository>();
var matchingCustomers = myRepo.GetCustomersWithOrdersPendingFor(new DateTime(2010, 12, 31));
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2番目の例では、クエリの意図を明確に示しており、将来の識別が容易/迅速になります。

ただし（問題を複雑にするために）、クエリ仕様を使用して複雑なクエリロジックを分離し、汎用リポジトリで使用して作業を完了することができます。それがどのように行われるかを確認するには、この投稿を参照してください。

私は通常次のことをします：

  1. 汎用リポジトリーを作成します（つまり、IRepository <TAggregateRoot>）
  2. IRepository <TAggregateRoot>を実装して、集約ルートごとにリポジトリを作成します
  3. 必要に応じて、適切なリポジトリにクエリメソッドを追加します
  4. リポジトリが肥大化しすぎた場合は、クエリを個別のクエリ仕様にリファクタリングします

最後の注意：私はかつて、オンラインモードとオフラインモードの両方で動作するアプリを設計しました。最も簡単な解決策は、2つの具体的なリポジトリを（共通のインターフェイスを使用して）実装し、クライアントが接続/切断されたときにそれらを切り替えることでした（永続化テクノロジを切り替える別の例）。

于 2010-12-30T10:17:02.757 に答える
1

LLBLGen でリポジトリを使用していますが、セルフサービスです。単体テストを容易にするためにリポジトリ パターンを使用しています。単純な挿入/更新の場合、リポジトリは渡されたエンティティの保存メソッドを呼び出すだけです。私たちが最終的に目指しているのは、リポジトリとビジネス ロジックの間でドメイン オブジェクト (LLBLGEN エンティティではない) をやり取りし、実装されたリポジトリに ORM (LLBLEN、LINQ-To-SQL など) の依存関係のみを持たせることです。

于 2010-12-22T16:42:52.410 に答える