使用 Unity 的 DI 和 IoC.组合根、工作单元 DDD 设计注意事项

本文关键字：单元 工作 DDD 注意事项 Unity DI 组合 IoC 使用 | 更新日期: 2023-09-27 18:32:19

美好的一天，

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

DAL [EF 5 DbContext] => 个实体

实体

[保存 EF 实体的单独程序集。

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

ISerivces [服务接口]

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

UI => 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 不应在任何地方引用。如果不应该引用它，你如何使用它？

谢谢

使用 Unity 的 DI 和 IoC.组合根、工作单元 DDD 设计注意事项

在组合根目录之外使用 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 实例，这也将处理后续的依赖链。

早上好，

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

在理想世界中，您的依赖关系将通过某种Web服务来解决（PS业务逻辑也应该发生同样的事情），但大多数时候这要么是不可能的，要么需要付出很多努力。在我以前的项目中，我在服务项目中有一个依赖容器（用于解决我的依赖关系），它引用实体等等。

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

相关文章：