好的，'Fat'模型和事务脚本都解决了与保持业务逻辑的位置相关的设计问题。我已经做了一些研究，并且流行的想法说，在模型中封装所有业务逻辑是要走的路（主要是因为事务脚本可能变得非常复杂并且经常导致代码重复）。但是，如果我想在业务逻辑中使用第二个模型的TDG，这是如何工作的？当然，事务脚本提供了一种更简洁，更少耦合的解决方案，而不是在另一个模型中使用一个模型？
一个实际的例子......
我有两个课程：User＆amp;警报。当将用户实例推送到数据库（例如，创建新的用户帐户）时，存在需要插入一些默认警报记录的业务规则（例如，默认的“欢迎使用系统”消息等）。我在这里看到两个选项：
1）将此规则添加为User方法，并在此过程中创建User和Alert之间的依赖关系（或者至少是Alert的Table Data Gateway）。
2）使用事务脚本，避免模型之间的依赖关系。 （此外，意味着业务逻辑保持在“中立”级别，并且可以通过Alert轻松访问。但这可能不太重要。）
然而，用户对自己的验证等负责，但由于我们正在讨论涉及两个模型的业务规则，因此事务脚本对我来说似乎是更好的选择。有人发现这种做法存在缺陷吗？
答案 0 :(得分：2)
考虑将部分业务逻辑转移到service layer
答案 1 :(得分：1)
对于业务逻辑很少的简单应用，请使用事务脚本。它是直截了当的（因为每个脚本通常使用软件用例进行映射）并且易于实现（例如，您不必像富域模型那样处理复杂的OR映射）。事实上，花费大量时间为简单的应用程序制作丰富的OO模型对我来说是一种过度工程化的行为。
对于更复杂的应用程序（或以前简单的应用程序变得更加复杂），您几乎肯定会看到转录脚本模式的缺陷，即代码重复和事务脚本中的僵化（现在可能已经成为大球泥）。在这种情况下，富域域层会更有意义。
通常，我会开始使用事务脚本构建应用程序，并在应用程序增长时慢慢将其重构为更丰富的域模型。
答案 2 :(得分：0)
取决于复杂性。正如Buu所说，这取决于您的应用程序复杂性。 TS快速而肮脏 - 这可能是您完成这项特殊工作所需的全部工作。话虽如此，IME，你为解决一个直接问题而编写的代码越多意味着代码会被应用到应用程序中并在后期增加你的重新分解开销 - 这反过来会降低执行该任务的可能性。从长远来看，它可能会使您的代码变得混乱。
我不会将该方法添加到用户 - 这不是用户“行为”。警报是否有资格作为域对象？我想我可能会为每个模型制作一个模型，并通过服务层（如Ray所提到的）协调更新，而不是直接耦合类。这样，您的View可以直接访问警报模型，并显示相对于当前用户记录的状态。