我目前正在使用asp.net Web Api（5.0.0-rc1）开发Rest API。到目前为止，我们不使用任何DI容器，所以它是“穷人的DI”。但是计划是很快使用一个或另一个。
为了解决依赖性，我们使用了自己的实现，IHttpControllerActivator类似于Mark Seemann的博客中的描述。
问题
我们所有的控制器都使用服务来执行其操作。我们还试图将控制器重用于不同的角色。Fe列出所有用户的控制器具有HttpGet属性
[HttpGet("api/role/{role}/users")]
因此，根据uri中的角色（可以是fe admin或department），我们希望以不同的方式解决控制器的依赖关系。这可能意味着我们想用装饰器包装服务，或者需要根据角色将某种策略注入服务。
注意：依赖关系的条件解析可能在依赖关系图中很深。
问题
由于我对依赖注入还很陌生，所以我真的不确定解决条件依赖的标准方法是什么。依赖注入是基于每个请求的条件，还是依赖图相当固定，在这种情况下我们应该使用工厂？Fe控制器ISomeServiceFactory代替了控制器ISomeService，工厂本身得到了注入角色。
我还查看了温莎城堡的类型化工厂设施，但不确定是否能解决我们的问题。
在我们当前的Java项目中,我们需要批量处理大量记录.完成此处理后,必须再次启动并再次处理所有记录.该处理必须并行化并且在多个节点之间分布.
记录本身存储在数据库中.使用一些id范围(例如1-10000)来识别批次就足够了.
从高层面来看,我看到以下步骤:
我们非常重视MongoDB,并考虑将子任务保存在其中.然后,每个节点都可以获取尚未完成的子任务,进行处理并将记录标记为已完成.一旦没有撤消的子任务,主任务将再次创建所有子任务.这可能会奏效,但我们正在寻找一种解决方案,我们不需要自己进行繁重的同步工作.