我一直在对依赖注入和服务定位器（以及两者之间的比较）进行大量研究。我绝对可以看到依赖注入的好处，尤其是在测试驱动开发方面。虽然我们目前没有实践测试驱动开发，但我想开始在我的开发团队中实施这种实践。但是，要求几乎所有的数据库调用都必须通过 Web 服务。对于新的开发项目，我们更常使用 WCF 服务而不是传统的 Web 服务。我正在努力理解的是将 Dataprovider 依赖注入到我们的 Web 服务中的想法。
客户端必须告诉服务从哪里提取数据对我来说不太有意义。仅将 WCF 服务与 Dataprovider 紧密耦合是否“可以接受”？这似乎打破了没有外部依赖的单元测试的基本思想。我将不胜感激有关此事的任何反馈。
【问题讨论】：
标签： wcf web-services dependency-injection
根据场景的复杂性，您可能希望为 WCF 服务应用程序构建一个解耦层，这就是使用控制反转的意义所在。
客户端显然不应该知道，更不用说告诉服务，使用什么数据提供者了。决定这一点是 WCF 服务的工作。您可以在 WCF 类构造函数中使用服务定位器，也可以使用 IInstanceProvider 或 ServiceHostFactory 注入所需的服务。
您可以自行决定您的 WCF 应用程序使用什么服务。
一种常见的解决方案是使用Repository pattern 抽象数据持久性，这很有意义，尤其是在您的 WCF 服务包含任何重要的业务逻辑时。在这种类型的场景中，您将构建执行所有数据提供者特定逻辑的存储库类。然后我可以模拟或存根这些类以启用对服务的单元测试。
在其他情况下，特别是当您的 WCF 服务公开 CRUD 操作而几乎没有业务逻辑时，我发现在服务端点和数据库之间构建一个额外的层是没有意义的。最终，在某个时刻，您的程序的some 部分需要了解数据库。使用 DI/SL/IoC 不应该是它自己的目标。
【讨论】：
客户端不会指定数据的来源。所有的依赖注入都会发生在服务器上。
【讨论】：