問題タブ [ddd-repositories]

私はリポジトリ パターンを使用しており、どのデータ型を返すべきか疑問に思っていました。私のデータベースには、固定長に基づいて分割する必要がある可変長の文字列があります。最初は、文字列を渡して、構成された列の長さに基づいてサービス レイヤーに解析を行わせることを考えていました。リポジトリ層から文字列を渡すという考えはあまり好きではなく、むしろ完全なオブジェクトを渡したいと思っています。文字列を渡すことは責任の分離が不十分であるように思えますが、リポジトリが文字列を解析する方法を取得するために別のメソッドに移動する必要があり、解析を実行することはリポジトリにとって負担が大きすぎるように思えます。この場合、レポとサービスの責任は何ですか?

ドメイン駆動設計では、エンティティのコレクションプロパティに部分的な値を設定できますか？

たとえば、Customer.Orders、Post.Comments、Graph.Verticesなどのプロパティには、常にすべての注文、コメント、頂点を含める必要がありますか、それとも今日の注文、最近のコメント、孤立した頂点を含めることができますか？

同様に、リポジトリは次のようなメソッドを提供する必要があります

等。？

ここには大きな設計上の欠陥がありますが、私はそれを解決するのに苦労しています：

ビジネスニーズは少し複雑なので、これをシンプルに保つようにします。購入のテーブルと返品のテーブルがあります。返品が行われた場合、データベース内で最も古い購入に返品する一致を見つけて、「返品が適用された」テーブルに記録する必要があります。

したがって、返品を挿入するときは、そのトランザクション内で、返品を購入レコードに適用する必要があります。

現在のところ、挿入用のリポジトリを呼び出すサービスがあります。サービスは、挿入されたレコードのキーが何であるかを知る必要があります。これにより、サービスは、そのキーを使用して「適用された」レコードを挿入することでトランザクションを終了できます。

リポジトリがこの種のデータを返すべきではないというのが私の理解であるため、基本的に行き詰まっています。これは、リポジトリがコレクションであるという考えを打ち負かしませんか？

代替手段は何ですか？

明確化：

Purchaseテーブル、Returnテーブル、およびAppliedテーブルがあります。

適用されたテーブルは次のようになりますpurchaseIdreturnIdqtyReturned

したがって、返品が挿入されるときは、購入のID（いくつかのビジネスルールによって決定されます）と新しく挿入された返品のIDが必要です。

従来のado.netを使用した集約ルートの簡単なCRUDステートメントを誰かに見せてもらえますか？前もって感謝します！

私はASP.NETMVCプロジェクトに取り組んでおり、FacebookConnectAPIを使用してFacebookと統合しようとしています。今、私は概念的なレイアウトがどのようになるかを想像するのに小さな問題を抱えています。私はMVCでリポジトリモデルを使用しています。私は自分のDBを持っています。FBからユーザーの情報を取得し、データベースにfb_uidを保存できるようにしたい（とにかく合法ですか？）また、ユーザーのミニフィードにストーリーを投稿できるようにしたいです。Userというモデルクラスがあります。このクラスには、内部DBとFBデータベースの両方からのデータを入力する必要があります。データベースと通信するためのリポジトリクラスがありますが、どこ/どの部分がFBと通信する必要があるのか​​本当にわかりませんか？FBDeveloperToolkitを使用することを考えましたが、このフォーラムで読んだことから、ツールキットは少し古くなっています！XFBMLと純粋なJavaScript関数を使用する必要があるかどうかわかりませんか？はいの場合、ユーザーのfb_uidなどのデータをDBに戻すにはどうすればよいですか？それは、プレゼンテーション層からAPI関数を直接呼び出すことを意味しますか？

誰かがこれで私を助けてくれますか？

ありがとう！

あるリポジトリが別のリポジトリにアクセスできることは一般的に許容されますか？特にこの場合、追加するエンティティを決定するために別の集約ルートを使用する1つの集約ルートがあります。これは、アイテム/アイテムタイプの関係に沿ったものです。アイテムタイプが集約ルートである理由は、単一のアイテムの範囲外の管理ツール内で個別に保守できるためです。

重要な場合は、リポジトリファクトリの実装を介してリポジトリインスタンスを作成するだけなので、具体的なクラス名で直接作成することはありません。アグリゲートがリポジトリを認識することはありません。

編集-詳細情報：

具体的な実装は、画像をドキュメントに添付できることです。ドキュメント上の画像を管理できるだけでなく、さまざまな種類の画像があります（たとえば、拡張機能ではなく、実装方法として定義されている種類）。ドキュメントアグリゲートは、これらのイメージを使用するシステム内の他の数種類のオブジェクトの1つであり、すべてが同じタイプを使用するわけではありません。ドメインサービスにルールを添付しますが、これはより具体的にはドキュメント集約の構築を対象としています。アグリゲートを構築するとき、特定のタイプの5つのイメージと、他の2つのタイプのそれぞれ1つがあります。これらは集約内の個別のリストに格納されるため、個別にプルします。検証は問題ではありませんが、ドキュメントを組み立てるときに評価される画像の種類を制限します。

Linq2sqlオブジェクトをコンストラクターでドメインオブジェクトに変換している間、Linq2sqlはTSQLを構築する方法を知らないようです。そのような：

ただし、設定可能な属性を使用する場合は問題ありません。

これらの属性を設定可能にしたくありません。どうすればこれを達成できますか？そして、linq 2 sql がどのように TSQL に変換されるかについて、誰かが考える材料を提供できますか? 前もって感謝します！

データベースに対してドメイン サービスをテストするために、他の人がどのようなアプローチをとるのか疑問に思っていました。ドメイン サービス自体をテストするために、ドメイン サービスで使用できる一連のモック リポジトリが既にあります。これらのモック リポジトリの構築の一部は、サンプルの集計と関連するエンティティを構築し、それ以外の場合はモデル内で使用されるのと同じビジネス ルールに対してそれらを検証することです。これは、インターフェイスが変更された場合に、エンティティ自体の潜在的な影響ポイントを検出するための優れた簡単な手段も提供します。

SQL ベースのリポジトリのライブ テストで見られる主な問題は、データベースの一貫性です。たとえば、テストが実行されると、「作成」の側面はすでに実行されています。データベースが元の状態ではなくなるため、それらを再度実行すると、明らかに障害が発生します。この種のテスト専用に使用されるミラーリングされたデータベースを作成することを検討していました。構造、プログラマビリティ、制約などを含む最小限のものになります。また、特定の確立されたテスト用に最小限のデータセットを提供します。私の考えでは、テストの実行を開始する前に、ベース データを使用してデータベースを「元の」状態にリセットするために呼び出すことができるストアド プロシージャを作成できます。

これは、機能が最初に検証された後、開発者のマシンではそれほど重要ではありませんが、ナイトリー ビルドの一部としてこれらのテストを実行することの重要性について詳しく調べています。これにより、テストが失敗した場合に、ターゲットの展開環境 (特にこの場合、テスト チームが使用する環境) を汚さないようにビルドを保留することができます。

必ずしもプラットフォームが重要だとは思いませんが、実装に固有の懸念がある場合に備えて、私の環境は次のようになります。

Windows 7 (開発) / Windows Server 2008 R2 (サーバー) Visual Studio 2008 Team Edition (C#) Microsoft SQL Server 2008 Standard (開発/サーバー)

チーム ビルドを使用してビルドを実行していますが、それはおそらく質問の範囲内の要因ではありません。

私は、集合体の一部であるエンティティの変化を検出するために、人々がどのようなアプローチをとったかを調べています。私はうまくいくものを持っていますが、私はそれに夢中ではありません。基本的に、私のリポジトリは、集約ルートの状態が変化したかどうかを判断する責任があります。集約ルートが呼び出され、集約内でBookエンティティが呼び出されたとPageします。には、コレクションに格納されたBook1 つ以上のPageエンティティが含まれます。Pages

主に、挿入と更新のシナリオは、集約ルートとそのエンティティを調べてキーの存在を判断することによって行われます。キーが存在する場合、オブジェクトは一度に基になるデータ ソースに保存されていると見なされます。これにより、更新の候補になります。しかし、それはエンティティのそれだけに基づいて決定的なものではありません. 集約ルートを使用すると、答えは明らかです。1 つしかなく、それが特異なエントリ ポイントであるため、キーの存在によって操作が決まると想定できます。私の場合、変更日を取得できるように、集約ルート自体を再度保存することは許容されるシナリオです。

エンティティ自体のこの動作を容易にするために、私のEntityBaseクラスには , の 2 つの単純なプロパティが含まれていIsUpdated()ますIsDeleted()。これらのデフォルトは両方とも false です。前述のように、キーの存在に基づいて判断できるため、新しいかどうかを知る必要はありません。実装のメソッド (この場合はページ) には、バッキング データ セットIsUpdated()を true に変更する各メソッドがあります。

したがって、たとえば、ページには、読み取り専用のプロパティUpdateSectionName()のバッキング値を変更するメソッドが呼び出されます。SectionNameこのアプローチは一貫して使用されます。これは、そのデータ設定を実行するメソッドでバリデーターの論理接続ポイントを許可するためです (エンティティが無効な状態に入るのを防ぎます)。最終結果はthis.IsUpdated() = true;、メソッドの最後に a を配置する必要があるということです。

集約ルートが のリポジトリに送信されると(または操作Save()へのロジック スイッチ)、 のコレクションを反復処理して、次の 3 つのシナリオのいずれかを持つページを探します。Insert()Update()PagesBook

1. 鍵がありません。キーのないAPageが挿入されます。
2. IsDeleted = true;削除は更新よりも優先され、削除はコミットされます - の更新は無視されますPage。
3. IsUpdated = true;ページの更新がコミットされます。

このようにすることで、Pages コレクション内のすべてをやみくもに更新することを防ぐことができます。たとえば、Book に数百の Page エンティティがある場合、これは困難な作業になる可能性があります。私は本のコピーを取得し、比較を行い、検出された変更 (存在および/または比較に基づいて挿入、更新、および削除) のみをコミットすることを検討していましたが、それは非常におしゃべりな方法のようでした。 .

主な欠点は、開発者がエンティティ内の各メソッドで IsUpdated を設定することを覚えておく必要があることです。1 つ忘れると、その値の変更を検出できなくなります。私は、透過的に変更にタイムスタンプを付けることができるある種のカスタム バッキング ストアのアイデアをいじりました。これによりIsUpdated、リポジトリが更新を集約するために使用できる読み取り専用プロパティを作成できます。

リポジトリは、集約ルートが追加されたときに生成されたタイムスタンプに基づいてアクションを実行する作業単位パターンの実装を使用しています。操作のために複数のエンティティがキューに入れられている可能性があるため、エンティティ操作はロールアップされ、エンティティが属する集約ルート操作が実行された直後に実行されます。さらに一歩進んで、エンティティ操作を処理する別の作業単位を作成し、エンティティで使用されるある種のイベント追跡に基づいていることがわかります (これは、市場に出回っている ORM 製品のいくつかが達成すると想定している方法です)。同様のレベルの機能)。

ただし、この方向に進み続ける前に、これに関するアイデア/推奨事項/経験を聞きたいです.

編集：知っておくと役立ついくつかの追加情報：

1. 私が現在取り組んでいる言語は C# ですが、これは理論的な議論に近いため、言語固有の情報をできるだけ多く出さないようにしました。
2. リポジトリ/サービス/エンティティなどのコード。は、Tim McCarthy の著書「.NET Domain-Driven Design with C#」の概念とCodePlexのサポート コードに基づいています。私が取り組んでいるものはほとんど一から書き直されていますが、それは採用されたアプローチのタイプの実行可能な理解を提供します.