问事务脚本是反模式吗？

EN

事务脚本绝对是，而不是反模式。

根据我对事务脚本的发现，它根本不是面向对象的。

你说得对，事实并非如此。然而，这一事实并不能使它成为反模式。尽管这是一种程序性方法，但实际上，它在一系列业务逻辑体系结构模式中仍有其正确的位置--你只需要知道在哪种情况下使用它是一种最佳实践--在这种情况下，它不是。简单地说:如果问题域非常简单，那么在业务逻辑中使用更复杂的模式是不值得的。

或者-正如福勒所写的：

什么时候使用它 事务脚本的优点在于它的简单性。以这种方式组织逻辑对于只有少量逻辑的应用程序来说是很自然的，并且在性能或理解方面几乎不涉及开销。

你可能会想到的反模式叫做http://martinfowler.com/bliki/AnemicDomainModel.html。当您打算并认为您正在构建一个域模型时--因为您的问题域足够复杂--但实际上您最终使用的是事务脚本--这是这样的情况，因为代码组织不好/ OO技能薄弱。

这是而不是反模式。事实上，大多数企业应用程序(我所看到的)都使用事务脚本，而不是丰富的域模型模式。

只有当您有相当简单的域实体到持久存储聚合(RDBMS表)的映射时，活动记录模式才是方便的。

数据映射器类似于ORM (Hibernate和朋友)。如果您的业务逻辑驻留在域实体中，则这些实体必须自己进行变异。在我看来，这种逻辑将变异状态的逻辑(使用ORM时所固有的)与状态本身结合起来。从外部查看域模型并将业务逻辑放入服务(事务脚本)会更简单。另外，如果您的业务逻辑卷很大，那么当相关代码分散在域实体中时，很难找到它(这就像将事务脚本混合在一起一样)。

但是，您不必以完全过程化的方式结束，因为您可以(而且应该)将您的服务分解为独立的、高度内聚力的“过程容器”。

TS不是OO也不是非OO。您可以在域模型方法、服务方法或高级应用程序方法中使用它。它只是意味着你可以阅读该计划的商业意图，而不需要通过百万次回调和“黑魔法”。

这就是微软引入异步/等待的原因。它将看上去模糊的发送-a-回调(委托)和退出，处理-回调的单独-方法(需要)风格-变成一个可读的事务脚本。

GOTOs是不好的，因为它们破坏了事务脚本的可读性流，使其成为一个糟糕的流。

( a)出错的事务脚本是反模式。例如，一个巨大的方法、没有或很少的方法调用等不同级别的操作在同一方法中(将它们重构为方法)。业务流程的离散步骤在一个方法中(将它们分解为方法或单独的类)。很多业务对象？使用DDD服务模式)。

不正确地使用TS是一种反模式。例如，大量的应用程序间消息传递、事件触发等等，这样您就无法通过阅读和查看业务流程(对技术应用程序的功能需求)。低层次的细节(技术)与功能工作相结合。一个应该在一个页面上可见的业务活动的分离。

TS的使用应该是分形的，每次缩小缩小到更详细的TS样式逻辑。高级:您可以看到方法调用和DDD服务的使用。中等水平可能有点混合。较低的部分主要是域对象方法/属性调用，其中有最好的逻辑细节。

把TS扔到总线下面，因为它可能被滥用，或者阻止它的使用，只是把它踢下来--不能分组和分开，不知道SRP (单一责任)/内聚力的开发工具也会破坏其他风格。答案是对他们进行业务流程的培训，并给出分组和分离的例子--这应该由业务/功能需求(垂直切片)而不是技术(水平切片)来完成。

1. 将只处理一个域对象或其类型的其他实例的逻辑放在DO中。不要引用域对象(person.orders)中的其他对象类型，也不要将任何东西注入域对象(其他DO或存储库等)。它违反了SRP，就像这样简单。方法中的低级事务脚本
2. 当您需要像person.orders这样的东西，或者感觉您需要注入一些东西时，就创建一个DDD服务(不是序列化的，每次使用后没有持久的属性)。注入，例如，一个人，和其他集合(存储库或IQueryable等)。在那里做工作。这里的中级事务脚本
3. 将域对象和DDD上的操作合并到DDD服务的“app方法”类别中。
4. 从程序的最高级别构造和调用这些

但是，在每个级别上，它看起来都像一个TX脚本，遵循规则。方法要小一点。到时候你就能读出来了！

注意:在另一个答案中提供的链接中，Fowler告诉您如何使事务脚本正确和错误：

https://www.informit.com/articles/article.aspx?p=1398617

他也暗示这不是OO。我认为你可以把它和OO混合起来，使用TS的优点(可读性和上百种优点)，还有几百种OO的优点。也就是说，您可以将TS元素放在域模型中，并在更高级别的TS中使用域模型。

还可以考虑将事务脚本定义为单个数据库事务。因为您的域模型不应该注入存储库(将域对象注入存储库)，因此您实际上可以这样组织它，将相关的存储库调用为(De)在最高级别上保持。但是如果不是这样的话，关键是要有一个可读的代码流，这些代码不能被过度分隔。

抨击TS的问题在于，它让人们认为SRP都是关于SoC (关注点分离)，他们从来不用担心凝聚力(保持相同的东西在一起，这也意味着SoC，但要求组织)。因此，出于好意的工程师只需将事物分成一百万块(因为更多更好)，就更难分辨逻辑了。