向 POCO 类添加方法
我有以下设置：MVC >服务>存储库。现在我想让用户能够向文档添加注释。只有与文档关联的用户（作为所有者或审阅者）才能添加注释，因此在我的 NoteService 中，我执行以下操作以确保用户对所选文档具有权限：
public Note GetNewNote(int documentID)
{
if (!userHasAccess(Thread.CurrentPrincipal.Identity.Name))
throw new BusinessLogicException();
// Other stuff here...
}
我的问题是，我应该在哪里定义 userHasAccess 方法？它在 NoteService 中没有任何意义，因为它正在检查文档。我可以在 DocumentService 中定义它，但是 NoteService 将需要访问它，这似乎会引入更多的耦合。
对我来说，在 Document POCO 本身上定义它然后调用 document.userHasAccess(...) 更有意义。这是好的做法还是域 POCO 应该仅限于简单属性？我担心这实际上是验证的一部分，并且通过将方法放置在 POCO 中，我将服务和 POCO 之间的验证分开。
我试图确保我的应用程序易于维护和测试。任何关于我应该如何解决这个问题的建议将不胜感激！
I have the following setup: MVC > Services > Repositories. Now I want to allow users to be able to add a Note to a Document. Only Users associated with the Document (either as owners or reviewers) can add Notes so in my NoteService I do the following to ensure the User has permission on the selected Document:
public Note GetNewNote(int documentID)
{
if (!userHasAccess(Thread.CurrentPrincipal.Identity.Name))
throw new BusinessLogicException();
// Other stuff here...
}
My question is, where should I define the userHasAccess method? It makes no sense in the NoteService as it is checking on a Document. I could define it in the DocumentService but will then NoteService will need access to this which seems to be introducing more coupling.
To me it makes more sense to define it on the Document POCO itself and then call document.userHasAccess(...). Would this be good practice or should a domain POCO be limited to simple properties? I am concerned that this is really part of the validation and that by placing the method in the POCO I am seperating the validation between Service and POCO.
What I am trying to ensure is that my application is easy to maintain and test. Any suggestions on how I should tackle this would be most appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与设计的其余部分保持一致是有意义的，虽然我不知道完整的设计，但我至少可以说 POCO 本身上名为 UserHasAccess() 的方法是有意义的。
不，域 POCO 应该包含与对象相关的逻辑（尤其是验证逻辑）。否则，它最终会成为一个没有行为的对象 - 这是你绝对应该避免的。
但是，不要混淆域（业务）对象和视图对象，它们通常包含很少的逻辑。
我将验证放在 POCO 中，将跨域逻辑放在服务中。
It makes sense to be consistent with the rest of the design, while I don't know the full design I can at least say that a method called UserHasAccess() on the POCO itself makes sense.
No, a domain POCO should contain logic (especially validation logic) related to the object. Otherwise, it ends up being an object with no behaviour - something you should definitely avoid.
However, don't get confused between a domain (business) object and a view object, which will typically contain little logic.
I'd put validation in the POCO, and cross-domain logic in the services.
任何域实体也可以包含验证方法。
Any domain entity can contain validation methods as well.
通过 Martin fowler 检查这一点
也可以通过 Martin fowler 检查这一点
Check this by Martin fowler
check this as well by Martin fowler