Question

我正在使用依赖注入。假设我有一个这样的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的Facade类，由OrderService继承，其中的组件在构造函数中声明，如：

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

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

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

更新

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

我所提到的框架示例是System.Windows.Forms.Form，其中我不使用任何IOC容器，也不确定依赖。

Answer 1

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

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是你的组合根，DI容器的包装。

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

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

在依赖注入中声明Facade类

1 个答案: