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

Question

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

1. EF - UoW / Repository - 服务 - 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方面，请参阅我应该在哪里注射Ninject 2+（以及如何安排我的模块？） （包括链接到副本）。

总结是单个组合根管理到绑定过程是正确的，所以最终你会得到一些东西 （参见@jgauffin答案），这将是InRequestScope ，并且正确地说它在CR中。

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

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

Answer 3

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

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

如果您在此处和此处需要更多建议。 甚至是Ayende的建议： 这里和这里