存储库/ HoW - 使用或不使用？

Question

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

1. EF - UoW / Repository - Service - Web 或
2. EF - 服务 - 网络

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

有人对此有任何好的建议吗？

我遇到的一个问题是，我将使用Ninject来连接它。在网络方面，如果我想将DbContext注入服务，则需要引用EF。这似乎不对。

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

有没有办法抵消这个？

Answer 1

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

服务层不应公开数据库实体。它应该暴露适当的业务/域模型。它们可能看起来也可能与db实体完全不同。

imho这就是存储库模式的好处。它采用业务模型表示并将其转换为数据库/ orm可以使用的内容（反之亦然）。

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

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

Answer 2

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

在ninject方面，请参阅Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)（包含指向副本的链接）。

总结是单个组合根管理到绑定过程是正确的，所以最终你最终会得到某些（参见@jgauffin答案）InRequestScope和右边可以说是在CR中。

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

1. 如果其下的某个乌龟使用DBContext可能是更好的管理方式，那么一直向下实施IDisposable。
2. （更理想情况下）让Controller以显式方式显式提交任何UOW（并处理失败）（这并不完全排除某些使用过滤器等进行全部处理）。我绝对不是说Controller应该直接与DBContext对话。

Answer 3

  

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

即使你自己现在重新使用Repository模式过度使用，EF本身也会使用DbContext实现UoW，使用DbSet实现Repository。因此，无需在您的架构中添加UoW / Repository。

如果您需要有关此here和here的更多建议。甚至是Ayende的建议：here和here