1

我正在使用依赖注入。假设我有一个这样的 OrderService 类：

public class OrderService{
    public OrderService(
        IOrderValidator validator
        , IOrderRepository repository
        , IOrderNotificator notificator){
        //assign global fields
    }

    public void SubmitOrder(Order ord){
        if(validator.IsOrderValid(ord)){
            repository.InsertNew(ord);
            notificator.Notify(ord);
        }
    }
}

现在我想创建一个外观类，例如TypeAOrderService，由 OrderService 继承，在构造函数中声明组件，例如：

public class TypeAOrderService : OrderService{
    public TypeAOrderService() : base(
        new OrderValidator(),
        new OrderRepository(),
        new OrderNotificator()) { }
}

（请注意，注入组件复杂性的实现在这里并不重要，adapter pattern尽管替换继承也是可以接受的）。

这里可能有缺点，因为我们没有在组合根处定义依赖关系。但是我想知道在某些情况下是否可以接受。尤其是framework component当通过访问 DI Container 并自己解决它来使用框架是相当奇怪的时候。

更新：

正如评论中提到的，目前我不使用任何 IOC 容器。我的观点是，在框架中使用 IOC 容器很奇怪，因为这意味着每个使用框架的应用程序都需要使用 IOC 容器。如果我的观点是错误的，请随时纠正我。

我所指的框架示例是System.Windows.Forms.Form我不使用任何 IOC 容器并且不确定依赖关系的地方。

4

1 回答 1

2

关于是否使用 IoC，我认为在框架库中使用 IoC 就可以了。这只是意味着你的框架有自己的容器和组合根，它们对任何消费者都是完全隐藏的。您可以创建易于使用的外观类。像这样的东西：

public class OrderServiceFacade
{
    private readonly IOrderService OrderService;

    public class OrderServiceFacade()
    {
        this.OrderService = ContainerWrapper.Container.Resolve<IOrderService>();
    }

    public void SubmitOrder(Order ord) {
        OrderService.SubmitOrder(ord);
    }
}

ContainerWrapper 是您的 Composition Root，它是 DI 容器的包装器。

internal class ContainerWrapper
{
    private Container _Container;
    public Container Container
    {
        if(_Container == null)
        {
            //initialize it
        }
        return _Container;
    }
}

当然，您需要 OrderService 和 TypeAOrderService 从新的 IOrderService 接口继承。这也将您的 TypeAOrderService 与您的 OrderService 分离，因为它可以在其构造函数中获取接口，而不是直接实例化特定的实现。如果您确实需要 TypeAOrderService 来调用 OrderService 上的方法，您可以使用装饰器模式并让 TypeAOrderService 将 IOrderService 作为附加依赖项。

于 2013-05-16T21:08:53.663 回答