DI 模式是否限制了昂贵的对象创建以及不经常使用的依赖项? [英] Is the DI pattern limiting wrt expensive object creation coupled with infrequent dependency usage?

问题描述

当涉及到典型的构造函数依赖注入时，我很难理解一个明显的模式问题/限制.例如，假设我有一个 ASP.NET MVC3 控制器，如下所示:

I'm having a hard time getting my head around what seems like an obvious pattern problem/limitation when it comes to typical constructor dependency injection. For example purposes, lets say I have an ASP.NET MVC3 controller that looks like:

Public Class MyController
    Inherits Controller

    Private ReadOnly mServiceA As IServiceA
    Private ReadOnly mServiceB As IServiceB
    Private ReadOnly mServiceC As IServiceC

    Public Sub New(serviceA As IServiceA, serviceB As IServiceB, serviceC As IServiceC)
        Me.mServiceA = serviceA
        Me.mServiceB = serviceB
        Me.mServiceC = serviceC
    End Sub

    Public Function ActionA() As ActionResult
        ' Do something with Me.mServiceA and Me.mServiceB
    End Function

    Public Function ActionB() As ActionResult
        ' Do something with Me.mServiceB and Me.mServiceC
    End Function
End Class

我很难接受的事实是，DI 容器被要求实例化所有三个依赖项，而在任何给定时间，可能只需要依赖项的一个子集此控制器上的操作方法.

The thing I'm having a hard time getting over is the fact that the DI container was asked to instantiate all three dependencies when at any given time only a subset of the dependencies may be required by the action methods on this controller.

似乎假设对象构建是廉价的，并且对象构建没有副作用，或者始终使用所有依赖项.如果对象构造不便宜或有副作用怎么办?例如，如果构建 IServiceA 涉及打开连接或分配其他重要资源，那么在调用 ActionB 时将完全浪费时间/资源.

It's seems assumed that object construction is dirt-cheep and there are no side effects from object construction OR all dependencies are consistently utilized. What if object construction wasn't cheep or there were side effects? For example, if constructing IServiceA involved opening a connection or allocating other significant resources, then that would be completely wasted time/resources when ActionB is called.

如果这些操作方法使用了服务位置模式(或其他类似模式)，那么就永远不会有机会不必要地构造一个将被使用的对象实例，当然，使用这种模式会附加其他问题，使其没有吸引力.

If these action methods used a service location pattern (or other similar pattern), then there would never be the chance to unnecessarily construct an object instance that will go unused, of course using this pattern has other issues attached making it unattractive.

使用 DI 的规范构造函数注入 + 接口模式是否基本上将开发人员锁定在某种限制"中，即依赖项的实现必须便宜地实例化或必须充分利用实例?我知道所有模式都有其优点和缺点，这只是 DI 的缺点之一吗?我以前从未见过它提到过，我觉得很好奇.

Does using the canonical constructor injection + interfaces pattern of DI basically lock the developer into a "limitation" of sorts that implementations of the dependency must be cheep to instantiate or the instance must be significantly utilized? I know all patterns have their pros and cons, is this just one of DI's cons? I've never seen it mentioned before, which I find curious.

推荐答案

如果您有很多字段未被每个成员使用，这意味着该类的内聚度较低.这是一个通用的编程概念 - 构造函数注入只是让它更明显.这通常是违反了单一职责原则的一个很好的指标.

If you have a lot of fields that aren't being used by every member this means that the class' cohesion is low. This is a general programming concept - Constructor Injection just makes it more visible. It's usually a pretty good indicator that the Single Responsibility Principle is being violated.

如果是这种情况，则重构(例如到 Facade Services).

If that's the case then refactor (e.g. to Facade Services).

创建对象图时不必担心性能.

说到副作用，(DI) 构造函数应该简单而不是有副作用.

When it comes to side effects, (DI) constructors should be simple and not have side effects.

这篇关于DI 模式是否限制了昂贵的对象创建以及不经常使用的依赖项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！