1

次のシナリオで、何がより良い、またはより正しいプラクティスと見なされるのか疑問に思っています。

NHibernateを使用して次のビジネスエンティティをマッピングしました。

  • WallPost
  • WallPostComment

壁には0から多数のWallPostがあります。WallPostには0から多数のWallPostCommentsがあります。集約ルートはWallです。

WallPostCommentをWallPostに追加するタスクを書いています。アプリケーションはMVCアプリケーションであり、新しいWallPostCommentを追加するリクエストには、コメントが属するWallPostのIDが含まれています。コメントを追加するには、追加する必要のある投稿を取得する必要があります。私の質問は:これを行うための最良/最も正しい方法は何ですか?

私はこれまでに2つのアプローチを試しましたが、非効率的ですが、1つはより「正しい」と感じています。別の、より効率的なアプローチは「間違っている」と感じます。

1)セッションからWall集約ルートをロードし、PostsコレクションからFirstOrDefaultを選択します。これは、集約ルートを介してウォールポストにアクセスしているという点で「正しい」と感じますが、これを行うと、すべてのウォールポストがデータベースからフェッチされます(無制限の結果セット)。

2)リクエストによって渡されたwallPostIdを使用して、セッションから直接ウォールポストをロードします。集約ルートを回っているため、これは「間違っている」と感じますが、データベースで1行のデータが1回ヒットするだけです。

どちらがより良いまたは好ましいアプローチですか?他にどのような提案がありますか?

4

2 に答える 2

2

WallPostは、それ自体が集約ルートになる候補であるようです。このように、WallPostには独自のリポジトリがあり、個別にフェッチして、WallPostとそのコメントを操作できます。また、集約ルート(WallPost)が別の集約ルート(Wall)を参照できる場合は問題ありません。

WallPostを集約ルートにするように設計を修正できない状況になった場合は、ロールインターフェイスフェッチ戦略の概念を利用して、リポジトリフェッチを完全にフェッチするのではなく、集約ルートの一部の側面で制限するように区別できます。すべてのウォールポストをフェッチせずにウォールアグリゲートルートをフェッチし、更新するために必要なウォールポストをフェッチする方法。

WallPostアグリゲートルートを作成できず、ロールインターフェイスやフェッチ戦略を適用したくない場合の最悪のシナリオでは、必要なウォールポスト(アグリゲートルートの投影)を正確にフェッチするコマンドハンドラーを使用してCommentWallPostCommand(Comment)というコマンドを作成できます。少なくとも明示的なコマンドを使用すると、設計がより明確で明示的になります。

于 2011-09-20T10:30:41.113 に答える
2

本当に壁はありますか?ウォールとドメイン内の他のアクターとの関係は何ですか?壁はユーザーとつながっており、ユーザーは単一の壁を持っていると思います。あれは正しいですか?この場合、壁は単にWallPostsと関連するコメントのコレクションです。この場合、WallPostは集約ルートであり、Wallはまったくありません。

于 2011-09-20T13:38:13.393 に答える