1

我知道这已经做过一百万次了，但我仍然有两种想法：

  1. EF - UoW / 存储库 - 服务 - Web 或
  2. EF - 服务 - 网络

似乎 UoW / Repository 层是多余的，因为您可以模拟 DbContext 等。这将使实现变得简单，并且使服务更接近 EF 似乎更加通用。

有人对此有什么好的建议吗？

不过，我对此有一个问题是我将使用 Ninject 进行连接。在 web 端，如果我想将 DbContext 注入到需要引用 EF 的服务中。这似乎是错误的。

kernel.Bind<FunkySoftwareContext>().ToSelf().InRequestScope();

有没有办法抵消这种情况？

4

3 回答 3

2

取决于您是否想要正确的抽象。

服务层不应公开数据库实体。它应该公开正确的业务/领域模型。它们可能看起来也可能不完全像 db 实体。

恕我直言，这就是存储库模式的好处。它采用业务模型表示并将其转换为数据库/orm 可以使用的东西（反之亦然）。

但是，如果您已经确定从 Entity 框架加载的对象是您的域/业务模型的完美表示，那么请继续跳过存储库。

我在这里写了一篇博客文章：http: //blog.gauffin.org/2012/06/protect-your-data/

于 2012-08-24T10:10:59.323 回答
1

（这将是一个评论，但它变得太大了！）如果你有 2 个问题，你应该问 2 个问题。如果这是一个 Ninject 问题，我会回答它，但标题表明不是。

在 ninject 方面，请参阅我应该在哪里使用 Ninject 2+ 进行注射（以及如何安排我的模块？）（包括链接到副本的链接）。

总结是单个组合根管理绑定过程是正确的，因此最终您将最终拥有一些东西（请参阅@jgauffin 答案），InRequestScope并且在 CR 中可以说是正确的地方。

其他方法（阅读所有 UOW MVC Repository InRequestScope Qs & As）归结为将业务层服务类注入到 Controller 类中

  1. IDisposable如果它下面的某个乌龟正在使用 DBContext，则一直向下实施可能是管理它的更好方法。
  2. （更理想地）让控制器以显式方式显式提交任何 UOW（并处理故障）（这并不完全排除使用过滤器等进行的一些包罗万象的处理）。我绝对不是说控制器应该直接与 DBContext 对话。
于 2012-08-25T07:33:02.777 回答
1

似乎 UoW / Repository 层是多余的，因为您可以模拟 DbContext 等。这将使实现变得简单，并且使服务更接近 EF 似乎更加通用

即使您自己现在也意识到 Repository 模式过度使用，EF 本身使用 DbContext 实现 UoW 并使用 DbSet 实现 Repository。因此，无需将 UoW/Repository 添加到您的架构中。

如果您需要更多关于这里和这里的建议。甚至来自 Ayende 的建议：这里和这里

于 2012-08-25T07:49:30.180 回答