依赖注入和其他构造函数参数-不好的做法？

Question

目前，我正在对依赖注入容器进行一些实验，这一次是关于团结。

考虑到以下接口：

public interface IPodcastCommService
{
    void Download();

    void Upload();
}

和下列执行情况：

public class PodcastService
{
     private IPodcastCommService commservice;
     private String url;

     public PodcastService(String url, IPodcastCommService commservice)
     {
         this.commservice = commservice;
         this.url = url;
     }
}

由于构造函数，我正在寻找一个将参数传递给它的解决方案，并找到它：

var p = container.Resolve<IPodcastCommService>(new ParameterOverride("url", myUrl));

到目前为止还不错，但同时我也读到了这门课的设计有多糟糕，是的，它看起来有点难看。但是，如何以一种优雅的方式向类传递参数呢？

我的第一个想法是把它作为一个属性来做，但是每次我需要它已经给出的Url时，我都必须检查它。

更新:我读到这是一个糟糕的设计的例子之一是：

但是，在某些情况下，您可能已经为“解决”操作传递自定义构造函数参数。有些人可能认为这是糟糕的体系结构，但也有一些情况，比如将DI容器带到遗留系统中，这可能需要这样的操作。

来源：http://mikaelkoskinen.net/unity-passing-constructor-parameters-to-resolve/

Answer 1

我不明白为什么您需要PodcastService与IPodcastCommService的组合，而不是已实现的IPodcastCommService，并通过字符串注入url。我不明白为什么你的设计不好。注射url是很好的IMHO。

如果您想出更好的方法，我认为可以通过注入上下文/配置来代替它，而不是本机数据类型。

public class PodcastService
{
     private IPodcastCommService commservice;
     private IConnectionContext connection;

     public PodcastService(IConnectionContext connection, IPodcastCommService commservice)
     {
         this.commservice = commservice;
         this.connection= connection;
     }
}

public interface IConnectionContext{
    string PodcastServiceUrl{get;}
}

但是，我发现它没有任何好处(除了可以处理会话/常量/静态字段)。

更新：

我发现了类似的关于糟糕的设计here的问题。总之，本机类型参数(string等)或自定义构造函数参数并不坏。只是需要将参数放到真正负责该参数的类中。如果在抽象工厂模式中处理if-else条件，则需要自定义构造函数参数。

Answer 2

在您的场景中，我认为通过构造函数的DI是非常好的。之所以认为它是一种更好的通过属性的方法，是因为它对可读性更好，即想象一下，如果必须注入20个属性，构造函数会是什么样子。

如果你只打算注入几个属性，那么做你所做的绝对没有坏处。如果您发现依赖项开始爬升，我会考虑采用属性类型方法。

Answer 3

也许是

container.RegisterType<PodcastService>(new InjectionConstructor("myUrlParameter"));

会做得更好，不是吗？

但是，如果您需要一个以上的podcastservice，而他们需要另一个url，参数覆盖是可以的。