問題タブ [repository-pattern]

優れたEntityFrameworkリポジトリコードサンプルまたはテンプレートを探しています。

少なくとも2つの他のクラスで使用されているリポジトリクラスがあります。このリポジトリクラスは初期化する必要があります-これはコストが高くなります（データベースのクエリ）。ここで、必要な場所にリポジトリの個別のインスタンスを作成します。重要なのは、リポジトリを作成するたびに初期化する必要があるということです。そのようなリポジトリをTDD対応になるように設計するにはどうすればよいですか？私の頭の中で最初に考えたのはシングルトンでしたが、それは解決策ではありません。

PersonRepository など、特定のエンティティのすべての永続化ロジックをカプセル化するリポジトリ クラスを作成しても、そのリポジトリ クラスが Unit of Work パターンまたは Identity Map パターンを実装していない場合、それは依然としてリポジトリと見なされますか? つまり、Unit of Work と Identity Map はリポジトリの実装に必要ですか? それとも、永続化ロジックをカプセル化する任意のクラスをリポジトリと呼ぶことができますか?

一つ付け加えておきたい。リポジトリがこれらのパターンを必要とせず、永続化メソッドの単なるコンテナである場合、リポジトリと DAO (データ アクセス オブジェクト) の違いは何ですか? 同じオブジェクトに対して複数の名前を作成しているだけですか、それともリポジトリが本来あるべきものの一部が欠けているのでしょうか?

私はDDDを使い始めたばかりなので、これはばかげた質問かもしれません...

実行時に値を取得するためにエンティティが (いくつかの IRepository インターフェイスを介して) リポジトリにアクセスしても問題ありませんか? たとえば、プロパティの「デフォルト」選択を強制したい:

私の質問は、このようなことを行うことが DDD の原則に対する恐ろしい違反であるかどうかです。そうでない場合、私の次の質問は、使用するリポジトリを提供する最良の方法は何ですか? Person オブジェクトの作成時に指定する必要がありますか?

ありがとう、P

リポジトリ パターン (MVC Storefront プロジェクトから) で Rob Conery のスピンを使用して DAL を実装しました。ここでは、Linq を使用してデータベース オブジェクトをドメイン オブジェクトにマップし、Linq to SQL を使用して実際にデータを取得します。

これはすべて素晴らしく機能しており、必要なドメイン オブジェクトの形状を完全に制御できますが、ここで質問したいと思っていた同時実行性の問題にぶつかりました。私は並行処理を行っていますが、解決策は間違っているように感じます (これらのぎこちない感情の 1 つにすぎません)。

基本的なパターンは次のとおりです。

したがって、その実装では、ドメイン タスクへのマッピングが原因で同時実行追跡​​が失われました。元のタスクを取得した時点でのタスクのデータコンテキスト リストであるプライベート テーブルを格納することで、元のタスクを取得します。

次に、この保存されたテーブルからタスクを更新し、更新したものを保存します

これは機能しています - 同時実行違反があると、必要に応じて変更競合の例外が発生します。

しかし、私はトリックを逃したと叫ぶだけです。

これを行うより良い方法はありますか？

datacontext の .Attach メソッドを見てきましたが、既に行っているのと同様の方法で元のバージョンを保存する必要があるようです。

また、ドメイン オブジェクトを廃止し、Linq to SQL で生成されたオブジェクトをスタックのずっと上に置くことで、これをすべて回避できることも知っていますが、同時実行の処理方法が嫌いなのと同じくらい嫌いです。

Rob のやり方に従って、Linq to SQL ウィザードによって生成されたクラスと、POCO であるこれらのクラスのコピーを用意しました。私のリポジトリでは、Linq to SQL モデルではなく、これらの POCO を返します。

これの利点は、POCO モデルを簡単にインスタンス化できるため、コードがよりテストしやすくなることだと理解しています。

私は現在、Linq から SQL、さらには Entity Framework に移行しており、EF ブックの半分ほど進んでいます。EF エンティティではなく、リポジトリから POCO を返すことで失うメリットがたくさんあるようです。

私はまだ単体テストを実際に受け入れていないので、これらの余分な POCO を作成し、それらにデータを入力するためのコードを書くのに多くの時間を無駄にしているように感じます。オブジェクトを追跡できないため、EF の多くの利点を失うことになります。

このすべての ORM/Repository について、比較的初心者にアドバイスがある人はいますか?

アンソニー

私は NerdDinner チュートリアルに取り組んできましたが、そのほとんどは理にかなっています。私がよくわからないのは、モデルオブジェクトではなく、リポジトリがコントローラーで直接使用される理由です。たとえば、独自のメンバーシップ システムを実装する必要があり、Login メソッドを含む AccountController がある場合、それを接続するための最適なソリューションは何でしょうか? 例えば

また

また

AccountController が AccountRepository から情報を取得して Account オブジェクトに渡すのではなく、Account オブジェクトで AccountRepository を直接使用することをお勧めします。

NerdDinner スタイル:

1 ログイン要求が受信される
2 AccountController は AccountRepository を使用して要求に基づいてログインの詳細を取得する
3 AccountController は Account オブジェクトを使用し、ステップ 1 からの情報を渡す
4 Account オブジェクトは要求を処理し、AccountController に通知する

私が提案していること：

1 ログイン要求が受信される
2 AccountController は Account オブジェクトを使用して要求に基づいてログインを処理する
3 Account オブジェクトは AccountRepository を使用してログインの詳細を取得する
4 Account オブジェクトは要求を処理し、AccountController に通知する

後者のスタイルの理由は、AccountRepository からログインの詳細が返された後、従うべきビジネス ルールがあるためです。たとえば、アカウントがロックされているか、アカウントが検証されているかなどです。 2段以上。後者のスタイルでは、AccountRepository を使用しながらすべてのロジックをまとめます。

それが理にかなっていることを願っています。

ある種のRepositoryクラスを実装しましたがGetByID、DeleteByIDメソッドなどがありますが、メソッドの実装に問題がありUpdateByIDます。

私はこのようなことをしました：

しかし、渡されたエンティティを更新していません。

誰かがそのような方法を実装しましたか?

参考までにやり方はこちらGetByID

[アップデート]

マークが正しく示唆したように、ローカル変数の値を変更しているだけです。では、この方法についてどうすればよいと思いますか? リフレクションを使用して、プロパティを から にコピーしentityますitem。