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

Question

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

一个实际的例子...

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

1) 将此规则添加为用户方法，并在此过程中创建用户和警报(或至少警报的表数据网关)之间的依赖关系。

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

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

Answer 1

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