是DI模式限制再加上罕见的依赖使用WRT昂贵的对象创建？ [英] 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.

推荐答案

如果你有很多未正在使用的每一个成员字段这意味着类的凝聚力低即可。这是一个通用的编程概念 - 构造器注入只是使它更加明显。它通常是一个pretty很好的指标，该单一职责原则被侵犯。

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.

如果说当时的情况下重构（例如，以门面服务）。

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模式限制再加上罕见的依赖使用WRT昂贵的对象创建？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！