其中一个比另一个更好吗？MyObject.DoSomething（）vs MyService.DoSomething（MyObject）
这是一个有效的问题吗？
我最近被告知，MyObject.DoSomething()是相当过时的，并且这样做的服务方式是首选。是对的吗？
例子：
public class Policy : ICancellable
{
public void Cancel()
{
// Code to cancel working with 'this'.
}
}
VS
public class PolicyCancellationService
{
public void Cancel(Policy policy)
{
// Code to cancel working with 'policy'.
}
}
如果这样做是使用的服务方式 - 可将物体对任何功能或应该仅仅是哑巴？
我最近被告知，
MyObject.DoSomething()是相当过时的，它的服务方式是首选。是对的吗？
两种方式都是有效的;你应该选择哪个导致高内聚和低耦合。作为一个经验法则，你应该首先尝试将它放在课程本身，即MyObject.DoSomething()。
您应该只使用一个单独的（服务）类，如果：
DoSomething功能不直接涉及到MyObject责任。如果你把一个不相关的方法放到MyObject，它会导致低凝聚力。MyObject不具备执行DoSomething所需的全部信息。如果您将此附加信息提供给MyObject，则会导致高耦合。在你的榜样，如果取消是一个政策的一个重要特征和政策具有所有必要的信息，以执行此操作，你应该把它保持在Policy类。
如果使用它的服务方式 - 对象是否可以对任何功能负责或者它应该是愚蠢的？
恰恰相反：您应该在域对象本身中保留尽可能多的功能。服务应限于协调多个域对象之间的活动;他们最好不要包含任何业务逻辑。
我想，在我看来，您使用的是第一种方法是围绕主OOP校长喜欢抽象，封装等
但是，第二种办法的重点是设计变更的校长可以更容易地重建/复测重新部署诸如接口隔离，依赖倒置等应用程序。
在我看来，没有过时的方法是首选的方法。
也许调用它的最重要的参数Service是进程间通信往往很慢，而这通常是使用服务的含义。如果管理不当，可能导致chatty interfaces性能不佳。
因此，明确建立这个边界是很好的，这将使人们意识到调用外部服务时可能存在的问题，因此他们会更好地决定何时调用服务。
现在，如果逻辑没有外部依赖关系，我可能会将它留在对象中，而不是完全称为“服务”。