如何使用 NHibernate 从聚合根的子集合中最好地选择单个实体？
我想知道在以下场景中什么被认为是更好或更正确的做法：
我已经使用 NHibernate 映射了以下业务实体：
- Wall
- WallPost
- WallPostComment
WallPost 有零到多个 WallPost。 WallPost 具有零到多个 WallPostComments。聚合根是 Wall。
我正在编写一个任务，将 WallPostComment 添加到 WallPost。该应用程序是一个MVC应用程序，添加新的WallPostComment的请求包含评论所属的WallPost的id。为了添加评论，我需要检索应添加到的帖子。我的问题是：最好/最正确的方法是什么？
到目前为止，我已经尝试了两种方法，其中一种感觉更“正确”，尽管效率低下。另一种更有效的方法感觉是“错误的”。
1) 我从会话中加载 Wall 聚合根，并从其 Posts 集合中选择 FirstOrDefault。这感觉“正确”，因为我通过聚合根访问墙贴，但这样做会导致从数据库中获取所有墙贴（无界结果集）。
2) 我使用请求传递给我的 wallPostId 直接从会话加载墙贴。这感觉“错误”，因为我正在绕过聚合根 - 但这是对数据库的单行数据的单次点击。
哪种方法更好或首选？您还有什么建议？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
真的有墙吗？墙与您所在域中的其他参与者之间的关系是什么？我猜测墙与用户相连，并且用户只有一面墙。这是正确的吗？在这种情况下，墙只是墙贴和相关评论的集合。在这种情况下，您的 WallPost 是您的聚合根，根本没有 Wall。
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.
看起来 WallPost 本身就是一个聚合根的候选者，
这样它就有了自己的存储库，您可以单独获取它并对其及其注释进行操作。当一个聚合根（WallPost）可以引用另一个聚合根（Wall）时，没有问题。
如果您遇到无法修复设计以使 WallPost 成为聚合根的情况，您可以利用 的概念角色接口和获取策略确实区分存储库获取限制于聚合根的某些方面，而不是完全获取它，这样您可以获取 Wall 聚合根而不获取其所有墙帖子，并获取所需的墙帖子进行更新。
最坏的情况是，当您无法创建 WallPost 聚合根并且不想应用角色接口和/或获取策略时，您可以使用命令处理程序创建一个名为 CommentWallPostCommand(Comment) 的命令，该命令将获取确切所需的 wallpost（聚合根的投影）并更新它，至少有明确的命令会让设计更加清晰明确。
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.