C# DI和IoC使用统一。组成根、工作单元DDD设计注意事项

你好

我需要验证以下设计是否合理：

DAL[EF 5 DbContext]=>实体

实体[持有EF实体的单独组件。]

服务[我想做的事情，如CRUD等]=>DAL和=>Entities=>iSeries设备

iSeries[服务接口]

IoC[我的带有Unity容器和静态构造函数的依赖工厂]=>iSeries设备、服务。（基本上，它将接口与其实现联系起来）

UI=>IoC、iSeries设备（以及临时实体和EF，我将在我的服务中使用DTO，因此无需引用EF）

没有BAL或BLL——我正在尝试将尽可能多的逻辑放入实体中（通过添加属性和方法的分部类，这些属性和方法执行BL）。当这是绝对不可能的时候，一些BL投入使用（尽管尽可能少…）

以下是我如何使用DI：

 private void button1_Click(object sender, RoutedEventArgs e)
    { 

        var svc = DependencyFactory.Resolve<IMyService>();
        var l = svc.GetProjects();
}

private void按钮1\u单击（对象发送者，路由目标）
{ 
var svc=DependencyFactory.Resolve（）；
var l=svc.GetProjects（）；
}

请，如果你有任何意见，如果这个设计是有意义的或没有。扩展性/性能方面的潜在问题

此外，这看起来与合成根模式相似，只是在那里它说你的IoC不应该在任何地方被引用。如果它不应该被引用，你怎么使用它呢

谢谢，

早上好

有一件事要考虑的是，业务逻辑往往会发生非常频繁的变化。因此，如果我是您，我不会在不同的程序集之间拆分它，因为您不一定要重新编译在更改BL后不打算重新编译的程序集

在理想情况下，您的依赖关系将由某种web服务解决（同样的事情也应该发生在业务逻辑上），但大多数情况下，这要么是不可能的，要么是需要大量的努力。在我的上一个项目中，我在服务项目中有一个依赖项容器（用来解析我的依赖项），它引用实体等等

希望这有帮助，

---

Alex D

在组合根目录之外使用DI容器很可能意味着您正在使用服务定位器（anti）模式。这将使您的代码与DI容器紧密结合，并使单元测试变得困难，因为服务定位器通常是静态类

您想要做的是构造函数注入，在构造函数中声明依赖项

public class Foo
{
    private readonly IBar _bar;

    public Foo(IBar bar)
    {
        if (bar == null)
        {
            throw new ArgumentNullException("bar");
        }

        _bar = bar;
    }
}

然后，您应该使用Unity来解析组合根中的Foo实例，这也将处理后续的依赖链