Question

美好的一天，

我需要验证以下设计是否有意义：

DAL [EF 5 DbContext] =＆gt;实体

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

服务[我想做的事情，如CRUD等] =＆gt; DAL和=＆gt;实体=＆gt; IServices

ISerivces [服务接口]

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

UI =＆gt; IoC，IServices（暂时实体和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();
}

如果您对此设计是否有意义有任何意见，请提出。可扩展性/性能的潜在问题？

此外，这看起来类似于组合根模式，只是说它不应该在任何地方引用你的IoC。如果不应该引用它，你如何使用它？

谢谢，

Answer 1

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

你想要的是进行构造函数注入，在构造函数中声明依赖项。

public class Foo
{
    private readonly IBar _bar;

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

        _bar = bar;
    }
}

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

Answer 2

早上好，

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

在理想世界中，您的依赖关系将通过某种类型的Web服务来解决（PS同样的事情也应该发生在业务逻辑中），但大多数情况下，它要么不可能，要么需要付出很多努力。在我之前的项目中，我在服务项目中有了依赖容器（用于解析我的依赖项），该项目引用了实体和诸如此类的东西。

希望这有帮助，亚历克斯D

DI和IoC使用Unity。组成根，工作单元DDD设计考虑因素

2 个答案: