OO 设计/模式 - 胖模型与事务脚本？

Question

好的，“胖”模型和事务脚本都解决了与保留业务逻辑的位置相关的设计问题。我做了一些研究，普遍认为将所有业务逻辑封装在模型中是可行的方法（主要是因为事务脚本可能变得非常复杂并且经常导致代码重复）。但是，如果我想在我的业务逻辑中使用第二个模型的 TDG，这将如何工作？与在另一个模型的业务逻辑中使用一个模型相比，事务脚本确实提供了一种更简洁、耦合更少的解决方案吗？

一个实际的例子......

我有两个类：用户和警报。当将用户实例推送到数据库时（例如，创建新的用户帐户），有一个业务规则也需要插入一些默认的警报记录（例如，默认的“欢迎使用系统”消息等）。我在这里看到两个选项：

1) 将此规则添加为 User 方法，并在此过程中创建 User 和 Alert（或至少 Alert 的表数据网关）之间的依赖关系。

2) 使用事务脚本，避免模型之间的依赖。 （此外，这意味着业务逻辑保留在“中性”类中，并且可以通过 Alert 轻松访问。不过，这在这里可能不太重要）。

然而，用户负责它自己的验证等，但是因为我们正在讨论涉及两个模型的业务规则，所以事务脚本对我来说似乎是一个更好的选择。有人发现这种方法的缺陷吗？

Answer 1

考虑将一些业务逻辑移入service layer

Answer 2

对于业务逻辑很少的简单应用，请使用事务脚本。它很简单（因为每个脚本通常都映射到一个软件用例）并且易于实现（例如，您不必像富域模型那样处理复杂的 OR 映射）。事实上，对我来说，花大量时间为简单的应用程序构建丰富的 OO 模型是一种过度设计的行为。

对于更复杂的应用程序（或者当以前简单的应用程序变得更复杂时），您几乎肯定会看到转录脚本模式的缺陷，即事务脚本中的代码重复和僵化（现在可能已经成为大泥球）。在这种情况下，富领域层会更有意义。

通常，我会开始使用事务脚本构建应用程序，并在应用程序增长时将其慢慢重构为更丰富的域模型。

Answer 3

取决于复杂性。正如 Buu 所说，这取决于您的应用程序复杂性。 TS 又快又脏——它可能是你完成这项特殊工作所需的全部。话虽如此，IME，您为解决当前问题而编写的代码越多，意味着代码会嵌入到应用程序中，并会增加您在后期的重构开销——这反过来又会降低执行该任务的可能性。从长远来看，它可能会使您的代码变得混乱。

我不会将方法添加到用户 - 它不是用户的“行为”。警报本身是否有资格作为域对象？我想我可能会为每个模型制作一个模型，并通过服务层（如 Ray 提到的）协调更新，而不是直接耦合类。这样，您的 View 可以直接访问 Alerts 模型并显示与当前用户记录相关的任何状态。