5

我目前正在使用 asp.net Web Api (5.0.0-rc1) 开发一个 Rest API。到目前为止,我们还没有使用任何 DI 容器,所以它是Poor Man's DI。但计划是很快使用一个或另一个。

为了解决我们的依赖关系,我们使用我们自己的实现,IHttpControllerActivator类似于Mark Seemann 的博客中描述的方式。

问题

我们所有的控制者都使用服务来执行他们的操作。我们也在尝试为不同的角色重用控制器。Fe 列出所有用户的控制器具有HttpGet属性

[HttpGet("api/role/{role}/users")]

因此,根据 uri 中的角色(可能是 fe admindepartment),我们希望以不同的方式解决控制器的依赖关系。这可能意味着,我们想用装饰器包装服务,或者我们需要根据角色向服务中注入某种策略。

注意:依赖关系的条件解析可能在依赖关系图中很深。

问题

由于我对依赖注入很陌生,我真的不确定解决条件依赖的标准方法是什么。依赖注入是否意味着以每个请求为基础,或者依赖图相当固定,在这种情况下我们应该使用工厂?Fe 是控制器ISomeServiceFactory而不是 aISomeService并且工厂本身获得了角色注入。

我还查看了 Castle Windsor 的Typed Factory Facility,但我不确定这是否能解决我们的问题。

4

1 回答 1

0

有多种方法可以将运行时值转换为多个可用依赖项(和整个子图)中的一种。与其依赖工厂,我更喜欢在可用的依赖项中进行选择。

到目前为止,我已经确定了至少三种不同的方法:

其中,我个人更喜欢Partial Type Name,因为它是最松耦合的。

所有这些选择策略都依赖于在选择之前可用的所有策略实例。通常,这不是问题,因为如果它们是线程安全的,则每个实例的单个实例可以在所有 HTTP 请求中重用。

然而,即使一项或多项服务不是线程安全的,也有一些方法可以处理潜在的性能问题——最显着的是使用虚拟代理模式。

于 2014-03-22T21:48:13.280 回答