我应该在哪里定义userHasAccess方法？

块引用>

这是有道理的符合设计的其余部分保持一致，虽然我不知道完整的设计，我至少可以说，一个在POCO本身叫UserHasAccess（）方法是有道理的。

  

如果一个域名POCO限于简单的属性？

块引用>

没有，一个域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!

Where should I define the userHasAccess method?

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.

Should a domain POCO be limited to simple properties?

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.

You are concerned that you are separating the validation between Service and POCO.

I'd put validation in the POCO, and cross-domain logic in the services.