問題タブ [repository-pattern]

私は、エディターとプロジェクトの概念を持つドメインモデルを持っています。

編集者は多数のプロジェクトを所有しており、プロジェクトには編集者の所有者だけでなく、多数の編集者メンバーもいます。したがって、編集者には多数の「参加」プロジェクトもあります。

私はこれをモデル化し、永続性のためにリポジトリパターンを使用するためにDDDアプローチを採用しています。しかし、私はまだパターンを十分に理解していないので、これをどのように行うべきかを判断できません。

私は、エディターとプロジェクトが潜在的に同じ集合体であり、ルートがエディターであるという前提で作業しています。したがって、エディターを取得してそのプロジェクトを列挙し、そこからプロジェクトのメンバーのエディターを列挙することができます。

ただし、リポジトリからのエディタの取得のみが許可されている場合、それを所有するエディタを取得するときに、リポジトリからすべてのプロジェクトをロードする必要があるということではありませんか？また、メンバーのエディターを遅延ロードする場合、プロジェクトにはリポジトリへの参照も必要ですか？

または、アグリゲートを分割してエディターリポジトリとプロジェクトリポジトリがある場合、新しいプロジェクトがエディターに追加されたときなど、2つの間でトランザクションをどのように処理する必要がありますか？例えば：

リポジトリパターンの意図を誤解していますか？

ぐるぐる回っている感じです。正しいリポジトリ パターンがLINQ to SQLを使用しているものについて、私は決心できないようです。Rob Conery の MVC Storefrontに精通している場合は、彼の実装が LINQ で生成されたモデルを別のクラスでラップし、LINQ で生成されたモデルを単にデータ転送オブジェクト(DTO) として扱っていることがわかります。次のようになります。

Mike Hadlowが IRepository<T> のバージョンでLINQ to SQL を使用した IRepository パターンの使用で提案している方法とは対照的に、この方法 (ラッパー クラスを使用) の利点は何ですか?リポジトリ？

ビジネス ロジックはどこで適用およびチェックする必要がありますか? これは、保存/更新時にリポジトリによってすべて一緒に呼び出される別のレイヤーにありますか、それともラッパークラスに組み込まれていますか?

注文をデータベースに保存するために Linq To SQL を使用する、よく使用する電子商取引コードがあります。密結合された Linq to SQL ビットを削除し、代わりに IRepository を渡したいのですが、まだ少し混乱しています。

Customer オブジェクトを返す ICustomerRepository に GetCustomer() メソッドがあるとします。

そのメソッドから返される ICustomer オブジェクトを実際に返す必要があるので、Linq から SQL に切り替えて SubSonic と言っても問題ありませんか?

その場合、Linq To SQL で、Linq To SQL Customer オブジェクトを SubSonics ExecuteSingle(Of ) メソッドのような ICustomer オブジェクトに簡単に変換する方法はありますか?

リポジトリ パターンを使用してトランザクション方式で複数のエンティティの保存をカプセル化するにはどうすればよいですか? たとえば、注文を追加し、その注文の作成に基づいて顧客ステータスを更新したいが、注文が正常に完了した場合にのみそうする場合はどうすればよいですか? この例では、注文は顧客内のコレクションではないことに注意してください。それらは独自のエンティティです。

これは単なる不自然な例であるため、注文が顧客オブジェクト内にあるべきかどうか、または同じ境界コンテキスト内にあるべきかどうかはあまり気にしません。基礎となるテクノロジ (nHibernate、EF、ADO.Net、Linq など) が使用されるかどうかはあまり気にしません。この明らかに不自然な操作の全か無かの例で、一部の呼び出しコードがどのように見えるかを確認したいだけです。

私はMVCアプリケーション用にいくつかのリポジトリを構築しており、リポジトリ間で責任を分担する正しい方法を考え出そうとしています。ほとんどの場合、これは明らかです。しかし、正しい答えが何であるかわからない特定のケースが1つあります。

このアプリケーションのユーザーは、従業員の複数のタイプの時間を追跡する必要があります。簡単にするために、2つだけを考えてみましょう。それらを「タイムカード」と「出席」と呼びます。これら2つの違いの正確な性質はそれほど重要ではありませんが、エンドユーザーはこれらを完全に別個のデータと見なしていることに注意してください。しかし、彼らがそれらを完全に別個のデータと見なす理由は、過去にそれらを一緒に見る機会が実際になかったからだと思います。どちらのタイプのレコードも、レコードの編集に関してほぼ完全に異なるビジネスルールを持っていますが、一般的に言えば、従業員が特定の時間にいた場所の両方のレコードでもあります。どちらのタイプの時間レコードにも、合計時間数など、多くの共通のプロパティがあります。と時間を収集した従業員。どちらのタイプにも、個々のタイプに完全に固有のいくつかのプロパティがあります。これらの「余分な」プロパティは、別のタイプのインスタンスに保持されています。したがって、一般的な構造は次のようになります。

したがって、問題は、ここで必要なリポジトリの数です。

1リポジトリ

リポジトリが1つしかない設計では、「タイムカード」、「出席」レコード、または両方のタイプを1つのリストに返すメソッドが公開されます。これはリポジトリのクライアントにとってはかなり便利ですが、私の考えでは、非常に太ったクラスになる危険性があります。「タイムカード」だけのリポジトリは、複雑なビジネスルールのせいで「出席」を処理しなくても、すでにシステム最大のリポジトリの1つになっていると思います。

2つのリポジトリ

別の設計には、「タイムカード」用の1つのリポジトリと、「出席」レコード用の別のリポジトリがあります。これには、たとえば「タイムカード」のビジネスルールがそれ自体で設定されているという利点があります。ただし、タイプに関係なく、すべての時間レコードのリストを取得する方法も必要です。この場合にどのリポジトリを使用するかは明確ではありません。両方？

3つのリポジトリ

「タイムカード」用の1つのリポジトリ、「出席」レコード用の別のリポジトリ、およびすべてのタイムレコードの読み取り専用リストを配信するための3番目のリポジトリを備えた設計も可能です。2リポジトリの設計と同様に、これには、たとえば「タイムカード」のビジネスルールがそれ自体で適切に配置されているという利点があります。結合されたリストをどこで入手できるかが明確になりました。しかし、2つの異なるリポジトリから同じレコードを取得できるのは少し奇妙だと思います。

ハイブリッド

ハイブリッドアプローチでは単一のリポジトリを使用しますが、ビジネスルールコード（レコードの選択を含む）を個別のタイプに移動します。この例では、単一の「タイムレコードリポジトリ」が「タイムカード」と「出席」時間のビジネスルール実装クラスのインスタンスを集約します。これが私が今好んでいるアプローチだと思います。

他の？

私が見逃したものはありますか？あるデザインを他のデザインよりも説得力のある議論はありますか？

私のリポジトリでは、Linq Entity クエリからドメイン オブジェクトへの割り当てを行っています。次に、リポジトリから返されたこれらのオブジェクトに作用するサービス レイヤーを用意します。

私のドメイン オブジェクトは、このようにリポジトリにある必要がありますか? それとも、リポジトリをエンティティとデータ アクセスに制限し、代わりにサービス レイヤーにドメイン オブジェクトへの割り当てを行わせる必要がありますか?

リポジトリですべての割り当てを行う方が簡単に思えますが、データベース オブジェクトとドメイン オブジェクトの違いがわかりません。ここでの適切な練習とは何ですか? ティア

次のように datacontext をプロパティとして設定する際に潜在的な問題はありますか?

リポジトリ

サービス層:

モデルエンティティに適合しない、または一部を拡張する、リポジトリからアドホック（ケースバイケースのカスタム）データを返すための推奨される方法は何ですか？

101の例は、ユビキタスなhellowordアプリケーションであるブログシステムです。投稿エントリに投稿エンティティに存在しない追加情報が含まれている投稿のリストをロードするとします。コメントの数と最後のコメントの日時だとしましょう。単純な古いSQLを使用し、データベースから直接データを読み取る場合、これは非常に簡単です。各投稿のコメントのコレクション全体をロードする余裕がなく、1回のデータベースヒットでそれを実行したい場合、リポジトリパターンを使用して最適に実行するにはどうすればよいですか？この状況で一般的に使用されるパターンはありますか？ここで、各ページにわずかに異なるカスタムデータが必要であり、完全な階層（パフォーマンス、メモリ要件など）をロードできない、適度に複雑なWebアプリケーションがあるとします。

いくつかのランダムなアイデア：

1. カスタムデータで入力できるプロパティのリストを各モデルに追加します。

2. サブクラスモデルエンティティはケースバイケースで、サブクラスごとにカスタムリーダーを作成します。

3. LINQを使用して、アドホッククエリを作成し、匿名クラスを読み取ります。

注：最近、同様の質問をしましたが、一般的すぎるようで、あまり注目されていませんでした。

例：

以下の回答の提案に基づいて、より具体的な例を追加します。これが私が説明しようとしていた状況です：

余分なことを何もせずに既成のORMを使用すると、n + 1クエリ、または1つのクエリですべての投稿とコメントが読み込まれる可能性があります。ただし、最適には、投稿のタイトル、本文など、コメント数、最新のコメント日付を含む投稿ごとに1行を返すSQLを1つだけ実行できるようにしたいと思います。これはSQLでは簡単です。問題は、私のリポジトリがこのタイプのデータを読み取ってモデルに適合させることができないことです。最大日付とカウントはどこに行きますか？

私はそれをどのように行うかを尋ねていません。リポジトリにメソッドを追加したり、新しいクラスや特別なエンティティを追加したり、 LINQを使用したりするなど、いつでもそれを行うことができますが、私の質問は次のとおりです。どうしてリポジトリパターンと適切なモデル駆動型開発が広く受け入れられているのか、それでも、この一見非常に一般的で基本的なケースに対処していないようです。