OO编码-是否使用对象管理器?

听起来你已经超越了将物体定义为“狗”的阶段 is-a 动物”并从以下方面进入对象定义 角色、职责和行为 .

我会推荐这本书来帮助你实现这种转变,真的” 明白 ":

Object Design: Roles, Responsibilities, and Collaboration

我无法回答你的具体问题,因为这是一个非常基本的设计决策,你真的应该了解“大局”。这本书将为你提供责任驱动设计的原则和技术的良好基础。

马丁·福勒有一些有用的 views on this .

基本的选择是在服务定位器和依赖注入之间。第一点是,这两种实现都提供了朴素示例中缺少的基本解耦——在这两种情况下,应用程序代码都独立于服务接口的具体实现。这两种模式之间的重要区别在于如何将实现提供给应用程序类。使用服务定位器,应用程序类通过向定位器发送消息来明确请求它。通过注入,没有明确的请求,服务出现在应用程序类中,因此控制反转。

控制反转是框架的一个常见特征,但这是有代价的。当您尝试调试时,它往往很难理解并导致问题。所以总的来说,除非我需要,否则我宁愿避免它。这并不是说这是一件坏事,只是我认为它需要为自己辩护,而不是更直接的选择。

让所有这些管理器类操纵轻量级对象感觉不太“面向对象”。

我不知道这是否非常“面向对象”,但对我来说,这感觉非常MVC和关注点分离。拥有非常轻量级的业务类(到目前为止,它们只是数据容器),然后是移动它们的存储库对象,这是一种常见的模式。

你可以继续重构User类中的所有功能,但正如你所说,你最终可能会一无所获。此时,你可以选择评估你创建的所有其他类,然后对每个类做出单独的判断,根据具体情况决定这些类是否包含足够的功能来保证一个全新的类。

如果您认为其中一些类太小,则可以将它们的功能放回User类中。例如,我认为在User上使用Validate函数没有什么错,而不是使用只有一个方法的UserValidation类。

当你说这些方法可能不属于用户对象时,我认为你是在花钱。获取/搜索/保存方法可能存在争议,但我认为它们不应该出现在业务对象本身上,而应该使用存储库(存储库模式)或通过 Query Objects 如果您不希望将ORM抽象到存储库中。

就身份验证而言,最好有一组负责身份验证的类,并将其完全从用户对象中删除。这组类可以知道用户对象,或者更好的是,它们应该知道诸如凭据之类的契约。

您所描述的情况与对象是否遵循自助服务或适配器模式保存到存储库(即数据库)有关。

自助服务将使对象保存“自己”,如 myObjectInstance.Save() ,而适配器模式将是 myObjectAdapter.Save(myObjectInstance) .

Adapter表单通常很受欢迎,因为它从对象中删除了任何存储库功能。

我喜欢用另一种方式来表达。这些方法并不真正属于该领域,因为不涉及业务逻辑。我想使用命令和查询隔离原则

GetByUsername()——这是一个真正不需要任何业务逻辑的查询

Authenticate()、VerifyLoginPassword()——这些是不应该在域中完成的验证逻辑。请参阅此文件 Set Based validation in Domain