美好的一天,
我需要验证以下设计是否有意义:
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 不应在任何地方引用。如果不应该引用它,你如何使用它?
谢谢
在组合根目录之外使用 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业务逻辑也应该发生同样的事情),但大多数时候这要么是不可能的,要么需要付出很多努力。在我以前的项目中,我在服务项目中有一个依赖容器(用于解决我的依赖关系),它引用实体等等。
希望这有帮助,亚历克斯·