【发布时间】：2019-03-05 04:15:57
【问题描述】：
据我了解 Application Service 层，它必须是无状态，即它不应该在属性或字段中存储任何动态数据。所以不同的应用服务实例会做几乎相同的事情。那么这是否意味着我们可以将其实现为 static 类或使用 singleton 模式？
【问题讨论】：
标签： design-patterns singleton domain-driven-design stateless
【发布时间】：2019-03-05 04:15:57
【问题描述】：
无状态服务应该在调用相关方法时传入所有状态。应用程序服务本身可能有其他需要注入的依赖项。
依赖倒置是你的朋友，我不推荐 static 类。而是使用一些带有单例模式的依赖注入，如果您愿意，我建议使用依赖注入容器，例如 Castle Windsor、StructureMap、Autofac、Ninject、Unity 或 SimpleInjector --- 我相信还有其他容器。
如果您遇到需要状态的单身人士，我会在上面写一个简短的video。
【讨论】：
我引用this pluralsight course by Julie Lerman & Steve Smith。
域服务应该是无状态的，尽管它们可能有边 效果。这意味着我们应该始终能够简单地创建 执行操作的服务的新实例，而不是 不得不依赖任何可能发生在 特定的服务实例。但是，当然，调用的结果 服务上的方法可能会导致系统状态发生变化 自己。
同样的概念也适用于应用服务。请注意，Stateless 并不意味着 static。例如，我们可以有一个EmailSenderService... 服务会发送一封电子邮件并可能返回成功/失败。稍后如果我们要发送另一封电子邮件，我们会实例化一个新的EmailSenderService 来发送电子邮件……我们不依赖于上一封电子邮件是否发送成功这一事实。
正如 Eben 所指出的，服务经常被注入到消费者中，static 类型不能被注入，这是不使用static 服务的一个很好的理由。
这是really good article by Jimmy Bogard about services in DDD。
我还建议检查此project by Dino Esposito，作为示例 DDD 项目。
【讨论】：
无状态性是一个有些负载的概念，人们用它来表示服务中的不同事物。
至少，它不应该记住关于两次调用之间的请求的任何信息。
根据扩展定义，它应该由它管理minimize the amount of state information。
无论如何，静态或单例都不是提供无状态服务的必要条件或充分条件。静态服务完全可以是有状态的，单例服务也可以。
换句话说，即使您使用非静态、非单例类，无状态的所有属性都可以成立。这可能应该是您的默认模式，除非您有很好的其他理由使用这些方法。
【讨论】：