我正在使用存储库和服务层设计模式构建ASP.NET MVC 5应用程序。我已经使用Unity将服务注入控制器。
这很好，直到现在，我一直不需要考虑实例化需要在控制器外部注入接口的任何对象。但是，在配置我的应用程序启动来设置数据库中的某些用户时，我需要此操作。
为此，我想用我构建的UsersService用户。随着应用程序的增长，我发生的情况肯定会有其他情况，例如从另一个服务中调用服务。
我看到我可以实例化统一容器并在其上调用解决方案以获取我的新实例：
IProductService productService = container.Resolve<IProductService>();
然而，这种气味使我闻起来，在我的应用程序上泄漏了容器似乎是一种反图案。那么有更好的方法吗？
统一和其他依赖注入容器会自动这样做。当您将服务注入控制器时，它将自动解析该服务的整个依赖关系图。不仅可以解决服务及其依赖项的依赖关系 can 您应该对需要它们而不是控制器而不是控制器的服务依赖项。
任何具有少数依赖关系的班级（包括控制器）是您违反单一责任原则的代码气味，您很可能应该重新分配服务。
是的，将容器注射到组成根部外的任何点都是一个称为服务定位器的反图案。
至于在控制器之外注射服务，区分注射时间和运行时数据很重要。例如，有些人试图将服务注入DTO对象，属性，静态类/扩展方法以及其他位置是抗pattern，以注入服务。在这些情况下，重要的是要正确评估对不同友好型解决方案的情况和重构 - 偏爱构造函数的注入而不是其他替代方案，并将服务定位者视为最后的度假胜地。例如，如果您试图用依赖服务制作扩展方法，那么您很可能具有本身应该是非静态服务的功能，绝不应该从DI容器中创建DTOS，您可能必须使用MVC中的多个扩展点，其中将容器注入了应用程序的组成词的组合词不构成服务定位器。
值得吗？通常。得到什么？您可以以与应用程序的设计师可能没有预期的方式更快地更改应用程序更快的能力更快。因此，确保申请被松散耦合的额外成本通常不仅仅是在项目的持续维护中收回。作为附带利益，您将获得轻松单位测试每个组件独立于其他组件的能力。