0

再会，

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

DAL [EF 5 DbContext] => 实体

实体 [持有 EF 实体的单独程序集。]

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

ISerivces [服务接口]

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

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。如果它不应该被引用，你如何使用它？

谢谢，

4

2 回答 2

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 的实例，这也将处理后续的依赖链。

于 2013-10-04T01:13:06.257 回答
0

早上好，

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

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

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

于 2013-09-20T13:24:42.020 回答