将哪些功能构建到业务对象中？答案

【问题标题】：What functionality to build into business objects?将哪些功能构建到业务对象中？
【发布时间】：2011-01-19 20:29:20
【问题描述】：

您认为至少应该将哪些功能内置到可持久化的业务对象中？

例如：

验证
一种与同一类型的另一个对象进行比较的方法
撤消功能（回滚更改的能力）

【问题讨论】：

类应该只有一种功能（单一责任原则）。当你想做多件事时使用多个类。
单一职责并不一定意味着该类只做一件事。如果一个 Policy 对象可以合理地获取报价、评价和发布，那么可能存在三种不同的方法，每种方法都做一件事。这三个方法都与一个 Policy 对象相关。我认为下面的 DDD 答案是正确的观点。
在 DDD 意义上，您可能会在每个验证上下文的单独对象中使用验证，您将使用工作单元或备忘录实现回滚，但可以创建您描述的 Policy 对象，包括等于方法。不同的东西属于不同的类，但相关的东西应该放在一起。尤其是在使用 DDD 时，使用不同名称的不同类可以为您的代码增加价值。

标签： oop persistence business-objects

【解决方案1】：

一个可持久化的业务对象应该包含以下内容：

数据
新
保存
删除
序列化
反序列化

通常，您会将功能抽象为将它们检索到支持的存储库中：

GetByID
全部获取
GetByXYZCriteria

您也可以将这种类型的功能包装到集合类中（例如 BusinessObjectTypeCollection），但是在使用领域驱动设计中的存储库模式来提供这些类型的访问器方面有很多进展（例如 InvoicingRepository.GetAllCustomers、InvoicingRepository.GetAllInvoices） .

您可以将业务规则放在新建、保存、更新、删除 ... 但有时您可以有一个外部业务规则引擎，您可以将对象传递给该引擎。

【讨论】：

【解决方案2】：

领域和业务规定的功能。

阅读Domain Driven Design。

【讨论】：

【解决方案3】：

这只是答案的一部分，但我想说您需要一种方法来获取与该对象有关系的所有对象。一开始你可能会尝试聪明一点，只为某些关系添加单向导航，但我发现这通常比它的价值更麻烦。

所有持久性框架还包括查找器、进行级联删除的方法……排序……

一旦开始建模，所有业务对象都应该知道如何管理自己。每当您发现另一个类过多地引用您的业务对象时，通常是时候将该行为推入业务对象本身了。

【讨论】：

【解决方案4】：

在问题中提到的三件事中，我想说验证是唯一真正需要的。其他的取决于应用程序的整体架构。

此外，业务规则应该在业务对象中。

一个对象是否应该进行自己的序列化是一个有趣的问题。过去，我通过让每个对象处理自己的序列化取得了巨大的成功，但我也看到了加载序列化模块并保存业务对象的优点，就像 GUI 写入和读取对象一样。然后您的验证也将防止数据库或文件中的错误。

我想不出一般需要的其他任何东西。

【讨论】：