How to best select a single entity from an aggregate root's child collection using NHibernate?

Question

I am wondering about what's considered the better or more correct practise in the following scenario:

I've mapped the following business entities with NHibernate:

• Wall
• WallPost
• WallPostComment

A Wall has zero-to-many WallPosts. A WallPost has zero-to-many WallPostComments. The aggregate root is Wall.

I'm writing a task to add a WallPostComment to a WallPost. The application is an MVC application, and the request to add the new WallPostComment contains the id of the WallPost to which the comment belongs. In order to add the comment I need to retrieve the post that it should be added to. My question is: what's the best/most correct way of doing this?

I've tried two approaches so far and one feels more 'correct', though it's inefficient. Another, more efficient, approach feels a 'wrong.'

1) I load the Wall aggregate root from the session and select FirstOrDefault from its Posts collection. This feels 'correct' in that I'm accessing the wall post via the aggregate root, but doing this results in all wall posts being fetched from the database (unbounded result set).

2) I load the wall post directly from the session using the wallPostId passed to me by the request. This feels 'wrong' because I'm going around the aggregate root - but it's a single hit on the database for a single row of data.

Which is the better or preferred approach? What other suggestions do you have?

Answer 1

Is there really a Wall? What is the relationship between a Wall and other actors in your domain? I would guess that a Wall is connected with a user and that a user has a single wall. Is that correct? In which case a wall is simply a collection of WallPosts and related comments. In which case your WallPost is your aggregate root and there is no Wall at all.

Answer 2

It seems that WallPost is a candidate to be an aggregate root itself, this way it has its own repository and you can fetch it separately and operate on it and its comments. and there is no problem when an aggregate root (WallPost) can reference another aggregate root (Wall).

If you comes into situation that you can't fix the design to make WallPost an aggregate root you can utilize the concept of Role Interface and Fetching Strategy do distinguish repository fetching to be limited on some aspects of the aggregate root instead of fetching it entirely this way you can fetch Wall aggregate root without fetching all its wall posts, and fetch the needed wall post to update.

Worst case scenario when you cant make WallPost aggregate root and you dont want to apply Role Interface and/or fetching strategy you can create a command called CommentWallPostCommand(Comment) with command handler which will fetch the exact needed wallpost (projection of the aggregate root) and update it, at least having explicit command will make the design more clear and explicit.