StructureMap - 将依赖注入到基类中？

在我的域中，我拥有少量的“处理器”类，它们拥有大量的业务逻辑。使用默认约定的StructureMap，我将注入库注入这些类的各种IO（数据库，文件系统等）。例如：StructureMap - 将依赖注入到基类中？

public interface IHelloWorldProcessor 
{ 
    string HelloWorld(); 
} 
public class HelloWorldProcessor : IHelloWorldProcessor 
{ 
    private IDBRepository _dbRepository; 
    public HelloWorldProcessor(IDBRepository dbRepository) 
    { 
     _dbRepository = dbrepository; 
    } 
    public string HelloWorld(){ return _dbRepository.GetHelloWorld(); } 
}

现在，有一些库，我想提供给所有的处理器，所以我做了一个基类是这样的：

public class BaseProcessor 
{ 
    protected ICommonRepository _commonRepository; 
    public BaseProcessor(ICommonRepository commonRepository) 
    { 
     _commonRepository = commonRepository; 
    } 
}

但是，当我的其他处理器继承从它，我得到一个编译器错误每一个说，没有构造函数的BaseProcessor，它采用零参数。

有没有办法做我想在这里做的事情？也就是说，为了让其他类可以使用的基类中注入通用的依赖关系，而不必将注入写入每个类中？

来源

2010-05-27 David

不是。这是C＃语言要求，而不是StructureMap限制。派生类必须将值传递给其基础构造函数。如果您仅仅使用基类来处理注入一个通用服务，那么您没有获得任何东西。只需在每个需要它的课程上安装通用服务 - 您的IoC工具将会处理它 - 这会带来什么危害？

来源

2010-05-27 19:49:20

我想这并没有真正的危害，我只是想整理一些东西。使代码更清洁一点。现在的折衷是在每个类的构造函数中包含公共依赖项，或者手动实例化基类中的依赖项（调用ObjectFactory.GetInstance（）而不是期待构造函数参数）。我想现在是抽出我的IoC容器的时候了，让第二个选项更舒服一点:) – David 2010-05-27 20:00:18

Nooooo ...那将会是一条糟糕的道路。仅仅因为您对构造函数参数数量感到不舒服而强制使用服务位置？请不要。如果你有一些常见的依赖关系（不只是一个），那么你可能有一些应该被分解到另一个服务中的通用功能。该服务将采用多个依赖项并执行需要它们的工作。然后您将该服务注入到其他构造函数中。这就是“支持构成而不是继承”的含义。 – 2010-05-28 12:57:01

你想要的是属性注入。基类可以拥有一个注入了依赖的公共属性，因为你永远不会使用派生类作为基类的具体实例 - 你将（应该）总是使用派生类的接口。

这里的答案是为了避免构造函数注入这个明显的弱点，并在你的基类中使用属性注入。

来源

2011-10-04 13:08:14 Bob

我会同意你，如果他有一个共同的基类建模的原因。但是他正在创建一个“人造”基础类，只是为了吸收依赖。没有好的结果，不管是否注资。 – 2011-10-05 02:45:27

StructureMap - 将依赖注入到基类中？

回答

相关问题