我目前正在使用asp.net Web Api（5.0.0-rc1）开发Rest API。现在我们不使用任何DI容器，所以它是穷人的DI。但计划是尽快使用其中一种。
为了解决我们的依赖关系，我们使用自己的IHttpControllerActivator实现，类似于Mark Seemann's blog中的描述。
问题
我们所有的控制器都使用服务来执行他们的行动。我们还尝试将控制器重用于不同的角色。
F.E.列出所有用户的控制器具有HttpGet属性
[HttpGet("api/role/{role}/users")]
因此，根据uri中的角色（可能是f.e. admin 或部门），我们希望以不同方式解析控制器的依赖关系。这可能意味着，我们希望用装饰器包装服务，或者我们需要根据角色在服务中注入某种策略。
注意：依赖关系的条件解析可能在依赖关系图中很深。
问题
由于我对依赖注入很陌生，我真的不确定解决条件依赖关系的标准方法是什么。依赖注入是指以每个请求为基础还是依赖图是相当固定的，我们应该在这种情况下使用工厂？ F.E.控制器获取ISomeServiceFactory而不是ISomeService，工厂本身将获得注入的角色。
我还看了一下Castle Windsor的Typed Factory Facility，但我不确定这是否能解决我们的问题。
答案 0 :(得分：0)
有多种方法可以将运行时值转换为几个可用依赖项（以及整个子图）中的一个。我宁愿选择在可用的依赖项中选择，而不是依赖工厂。
到目前为止，我已经确定了至少三种不同的方法：
其中，我个人更喜欢部分类型名称，因为它是最松散耦合的。
所有这些选择策略都依赖于选择之前可用的所有策略实例。通常，这不是问题，因为如果它们是线程安全的，则可以在所有HTTP请求中重用每个实例的单个实例。
但是，即使一个或多个服务不是线程安全的，也有ways to deal with potential performance issues - 最值得注意的是使用虚拟代理模式。