我一直在阅读 DDD，我认为我可能错误地使用了服务，或者至少以不太理想的方式使用了服务。我的服务类往往有很多包含存储库引用的实例变量，它们似乎做了很多工作（即有很多方法）。
创建更有针对性的服务是否可取？就像每个服务执行某种特定逻辑的一种方法一样？此外，服务类是否应该将实例变量存储到其他实体？我读过一些关于服务是无状态的，我不确定我是否通过拥有这些实例变量而违反了该规则。
谢谢！
问问题
1536 次
2 回答
14
我的服务类往往有很多实例变量......
这不一定是代码气味。如果您的服务需要许多依赖项来完成其工作，那么这就是一个事实。
...他们似乎做了很多工作（即有很多方法）。
创建更有针对性的服务是否可取？
作为一般规则，您可以使您的服务接口越细化（即方法越少）越好（曾经必须在一个接口中搜索五十个方法来寻找您想要调用的方法？）。但是，除非您作为公共 API 发布，否则您的服务接口的粒度可以随着您的进行而改进。通常，在开始一个项目时，我会从一项服务开始，然后随着时间的推移将其拆分。如果你是这些服务的消费者，那么当你开始感受到接口变大的痛苦时，你就会知道是时候分解它了。当然，如果这是一个公共 API，那么您将不得不做更多的前期设计。
此外，服务类是否应该将实例变量存储到其他实体？我读过一些关于服务是无状态的，我不确定我是否通过拥有这些实例变量而违反了该规则。
将依赖项存储为实例变量并不一定意味着您的服务不是无状态的，只要实例变量也是无状态的。要被认为是无状态的，服务上的方法调用不能以任何方式依赖于之前被调用的方法。您应该能够加载单个服务实例，并为您的应用程序共享它（即，无状态服务的实例不应特定于特定用户的会话）。换句话说，您的服务不应该在方法调用之间保持任何状态。将无状态存储库依赖项作为变量存储在服务实例上并不违反此要求。
The reason stateless services is a desirable goal, is having no state greatly reduces the possibility of bugs. It simplifies the testing of a service method by restricting the test-cases to varying the parameters passed in, rather than having to worry about the previous state of the service. It can also offer performance benefits.
于 2010-08-11T06:57:38.870 回答
0
我建议阅读依赖注入、控制反转等。
这是 Fowler 的文章：http ://martinfowler.com/articles/injection.html ，虽然我总觉得他有点过头了。我会尝试浏览一个表示使用 DI/IoC 容器的教程。
于 2010-08-10T18:59:16.580 回答