我的存储库/服务应该承担多少责任？
我有以下对象：
人员 <- 联系人 -> ClientsPerson <- Client
我正在使用带有服务层的存储库模式。但既然已经到了这里，作为一个完美主义者，我就迷失了！
我还有一个 PersonService、ClientService，我很确定我需要一个 ContactService，它应该调用 personService.Add(person) 和clientsPersonService.Add(client) - 或者？
该工作是添加联系人。该联系人将有一个相关的 Person 对象和一个 ClientsPerson 对象。 ClientsPerson 会这样做。有一个客户。
不同的工作应该去哪里？我听说从一个服务/存储库调用到另一个服务/存储库是很糟糕的。
I have the following objects:
Person <- Contact -> ClientsPerson <- Client
I'm using the repository pattern with a service layer. But already here, being a perfectionist, I'm lost!
I also have a PersonService, ClientService and I'm pretty sure I need to have a ContactService which should call the personService.Add(person) and clientsPersonService.Add(client) - or?
The job is to add a contact. The contact would have a Person object related, and a ClientsPerson object. And that ClientsPerson would ofc. have a Client.
Where should the different jobs go to? I've heard it's bad to call a service/repository from one to another.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个答案取决于您的 ORM 以及它如何级联保存。我们假设您没有使用级联更改的 ORM。
您的服务层方法应该反映您需要从业务角度完成的操作。我经常发现我的控制器操作与服务方法非常匹配。
在您的示例中，我将构建服务并与必要的实体相关联，并与存储库对话以保存它们；这样，如果在与存储库对话的过程中出现问题，它可以自行回滚并执行任何必要的清理工作。
回购应该是相对愚蠢的。服务应该负责关系和业务工作（除了 NHib 之类的东西，甚至可能是这样）。
This answer depends on your ORM and how it cascades saves. We will assume you aren't using an ORM that cascades changes.
Your service layer methods should reflect the actions that you need to accomplish from a business sense. Frequently I find that my controller Actions match up very closely to service methods.
In your example, I would have the service build and relate to the necessary entities and talk to repos to save them; that way if there is a problem along the way of talking to the repos it can roll itself back and do whatever cleanup is necessary.
Repos should be relatively dumb. Services should do the relationship and business work (barring something like NHib, and maybe even then).