0

私は次のことを行います：

    var @case = new Case
    {
        Name = "test"
    };

    // User is persistent and loaded in the same session
    User.AddCase(@case); // sets @case.User = User too
    Session.Update(User);

    response.CaseId = @case.Id;

User.Cases のカスケードは All に設定されています。ただし、トランザクションがコミットされるまで @case.Id は設定されません。それは期待される動作ですか？コミットする前にIDを取得したいと思います。それはできますか？

4

2 に答える 2

1

より純粋な DDD っぽい感じは、おそらく と の両方UserをCase集約ルートとしてモデル化し、ロール オブジェクトとの関係をモデル化することRelatedCaseです (これは内部Userで集約されているため、cascade="all-delete-orphan" にする必要があります)。

集約ルートはリポジトリに保存する必要があります。これにより、(呼び出しを に委譲した場合session.Save(...)) 使用できるときに必要な ID が得られます。

次に、ロールには、関係を特徴付ける追加情報を含めることができます (私の経験では、少なくともしばらくすると、多くの場合、ユーザーにもケースにも属さない追加情報が含まれます)。この関係は、ユーザーとケースが関連付けられている理由を追跡しているとします。

このようにして、コードは次のようになります。

var case = caseFactory.Create("name");
caseRepository.Save(case);

user.AssignCase(case, "Assigned by some dude");

-そして AddCase 内:

public void AddCase(Case case, string reason)
{
    cases.Add(new RelatedCase(case, reason));
}

私の意見では、これはこの種のものをモデル化する最も美しい方法ですが、もちろん、パフォーマンスに関して少し不利になります。きれいなモデルの方が重要な場合は、このようなモデルを選択する必要があります.

于 2010-03-17T12:40:31.173 に答える
0

試しましたSession.SaveOrUpdate(User)か？カスケード操作は必要になるまで行われず、フラッシュ/コミット時に発生すると言わざるを得ませんが。あなたSession.Save(@case)がフラッシュ/コミットしていないとき

あなたは論理的な間違いを犯していると言っていました.@caseを作成しても、ユーザーを更新していません. ユーザーは別個のエンティティでありCase、ユーザーへの外部キーを持っています。したがって、ケースを保存することは適切であり、ユーザーのケースのリストは単なる関連付け情報です

于 2010-02-13T13:12:44.310 に答える