我有一个存储应用程序状态的服务。出于这个原因，我把它变成了单身。它被传递到一些WebAPI控制器的构造函数中，以暴露它的一些状态和函数。永久性参考由后台工作人员持有，他们不断地做事并进行状态改变。 此状态服务具有一定的持久性，因为某些更改会导致db写入。这些都是非阻塞的，但除此之外。单个服务需要引用一个或多个存储库。存储库只是一个泛型类，它具有给定类型的get和insert方法。它将IDbConnection传递给它的构造函数。它们自己的存储库被传递给单例服务构造函数。
DI完成了链的构建，并且由于单个对象（服务）而导致错误，这取决于瞬态对象（存储库）。起初我并不是很明显，但这确实有意义并且可能导致并发问题。
https://simpleinjector.readthedocs.org/en/latest/LifestyleMismatches.html
DI建议是使依赖单身，使所有者不单身或者在工厂中为奴隶而来。这就是我的困境。
我们谈论的是单身和非单身之间的界面以及如何弥合这种界面。该服务需要是图表最左边的单例，并且IDbConnecton必须是最右边的瞬态，因此需要工厂作为桥梁，但需要放置它。
我可以注入一个创建存储库的工厂，但这意味着为每个存储库操作创建一个新的存储库对象。这似乎是一件非常浪费的事情。不可否认，存储库并不存在任何状态，但确实使存储库本身成为单例并为其提供生成IDbConnections的工厂似乎是合乎逻辑的。
工厂实际上可以只包装一个连接池，但这是一个重要的细节。感觉有点脏，使得存储库单例来满足依赖链，即使它在我认为通过时确实有逻辑意义。 如果有人能够理智地检查我，我会对它进行评价。感觉我的推理中存在某种错误，或者我正在啃着我不知道的模式的边缘。
答案 0 :(得分：1)
正如我正在阅读的那样，在你介绍它之前，我已经想到了工厂方法。对我来说，RepositoryFactory似乎是最有吸引力的方法，因为它们听起来很便宜，然后可以给它们可能需要的任何范围依赖。即跨多个存储库共享的连接。