为什么我不应该将我的服务设置为单例（IOC）？
为什么我不应该将我的服务设计为单例（IOC）？
在很大程度上取决于你的服务在做什么。通常情况下，如果存在某些共享状态，你可以选择使用单例模式，但是在这种情况下，对该状态的同步可能会导致性能瓶颈，从而影响可扩展性。如果没有共享状态，你仍然可以选择使用单例模式，但是必须小心，以免在将来引入任何共享状态（或者在引入共享状态时对其进行有效的锁定）。
如果每次都返回一个新的服务实例，那么你就不必担心这个问题，并且这可能会在未来带来更好的可扩展性/灵活性，尽管返回一个新实例也可能会影响可扩展性，如果该实例持有稀缺资源（例如数据库连接）。
因此，我认为真正的答案是“这要视情况而定”。如果你看一下框架是如何处理这个问题的，通常会采用一些中间方案，例如维护一组服务的池（例如数据库连接池）或Wcf的“每个会话”模型。
为什么不应该将服务设计为单例模式（控制反转）？
在进行更多的研究后，我发现不应该将服务设计为单例模式的原因。一方面，使用较短的生命周期可以更容易处理与会话特定信息相关的问题。混合不同的生命周期可能会使事情变得更加复杂。
当我们在单例服务中使用作用域依赖项时，一开始一切都会正常工作。然而，作用域服务通常不设计为长时间运行。如果它们使用外部资源，比如套接字连接或数据库连接，那么在某个时刻可能会丢失连接。由于作用域服务并不设计为长时间运行，它很可能会开始出现故障，从而导致单例服务也开始出现故障，并且这种情况将持续到应用程序重新启动。
另外，我的WordPress安装遭到了黑客攻击，所以我已经删除了相关链接。
解决这个问题的方法是将服务设计为短时间生命周期，例如使用作用域生命周期，而不是单例模式。这样可以避免混合不同生命周期造成的复杂性，并且可以更好地处理与会话特定信息相关的问题。