S#arp 架构：该域逻辑放在哪里
回复：S#arp 架构
一个关于 S# 中某些类型的域逻辑放在哪里的菜鸟问题arp。好的，想象一下这个域规则：
当按名称请求特定聊天室时，如果该聊天室已存在，则返回该聊天室，否则使用该名称创建一个新聊天室并将其返回。
这是领域逻辑吗？在这种情况下，我如何在我的实体对象中实现它（因为我似乎需要访问存储库才能做到这一点）
这是控制器逻辑吗？在这种情况下，我想我会把它放在 MVC 控制器中，很简单。
这是数据访问逻辑吗？在这种情况下，我将其构建到存储库对象中，然后控制器调用它。再说一遍，很容易。
我认为这是领域逻辑，但我不确定如何将其构建到我的实体中。由于实体似乎无法访问存储库（或者我错过了什么？）。
A bit of a noob question about where to put certain sorts of domain logic with S#arp. OK, so imagine this domain rule:
When asking for a specific chat room by name, return the room if it already exists, or else create a new one with that name and return it.
Is this Domain Logic? In which case, how do I implement it in my Entity object (as I seem to need access to the Repository to do it)
Is this Controller Logic? In which case I guess I stick it in the MVC controller, easy enough.
Is this Data Access Logic? In which case I build it into the Repository object and the Contoller calls it. Again, easy enough.
I reckon this is Domain Logic, but then I'm not sure how to built it into my Entity. As Entities dont seem to access to Repositories (or am I missing something?).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从您描述的方式来看，我认为这最好放在应用程序服务层中。 （WhoCanHelpMe? 示例项目中的任务层）。对我来说，这是应用程序逻辑而不是领域逻辑。
对于其他选项：
我不愿意将逻辑直接放入存储库的原因之一是清晰度。如果你在 IChatRoomRepository 上有方法：
如果给定的 id 没有空间，通常 GetRoomById 会返回 null，所以如果你还没有房间，第一个方法将默默地创建（并且可能持续？）一个房间，这并不是太明显。
更概念性地，摘自快速 DDD (p56)：
这表明如果您尝试实现存储库模式，则应在存储库外部创建新的聊天室。
From the way you've described it, I'd say this would best go in the Application Services layer. (the Tasks layer in the WhoCanHelpMe? example project). For me this is application logic rather than domain logic.
For the other options:
One reason I'd be uncomfortable putting the logic directly in a repository is clarity. If you have methods on IChatRoomRepository:
typically GetRoomById would return null if there is no room for the given id, so it's not too obvious that the first method will silently create (and presumably persist?) a room if you don't already have one.
More conceptually, from DDD Quickly (p56):
which would suggest that if you're trying to implement the repository pattern, the creation of a new chat room should happen outside the repository.