>持久性
> OO数据视图
>数据访问逻辑抽象
>查询访问逻辑
此外，我看到的仓库模式的大多数实现遵循此实现模式 – 假设我们正在开发博客应用程序。
NHibernate实现：
public class PostRepository : IPostRepository
{
private ISession _session;
public PostRepository(ISession session)
{
_session = session;
}
public void Add(Post post)
{
_session.Save(post);
}
// other crud methods.
}
实体框架：
public class PostRepository : IPostRepository
{
private DbContext _session;
public PostRepository(DbContext session)
{
_session = session;
}
public void Add(Post post)
{
_session.Posts.Add(post);
-session.SaveChanges();
}
// other crud methods.
}
在我看来，当我们使用ORM – 如Nhibernate或实体框架 – 创建这些存储库实现是多余的。此外，由于这些模式实现不会超过ORMS中已经存在的内容，所以这些模式比有帮助的OO抽象更像噪声。似乎使用存储库模式在上面提到的情况只是开发人员自我扩大和更多的pomp和仪式没有任何可实现的技术的好处。你怎么看 ？？
解决方法
如果你想要能够切换ORM或能够轻松地测试使用数据库层的类：是的，你需要一个存储库(具有接口规范)。
您还可以切换到内存存储库(我在我的单元测试中执行)，XML文件或任何如果您使用存储库模式。
更新
Googling可以找到的大多数存储库模式实现的问题是，它们在生产中不能很好地工作。他们缺乏限制结果(分页)和命令的结果，这是一个惊人的选项。
当它与UnitOfWork实现结合并且支持规范模式时，存储库模式来到它的荣耀。
如果你发现一个有所有这一切，让我知道:)(我有我自己的，一个良好工作规范部分的例外)
更新2
存储库不仅仅是以抽象的方式访问数据库，例如可以通过ORM来完成。正常的Repository实现应该处理所有聚合实体(例如Order和OrderLine)。在同一个存储库类中处理它们，你总是可以确保那些是正确的。
但是你说：这是由ORM自动完成的。嗯，是的和没有。如果您创建了一个网站，您最有可能只想编辑一个订单行。是否获取完整的订单，循环通过它找到订单，然后将其添加到视图？
通过这样做，你会引入逻辑到你的控制器，不属于那里。当web服务想要同样的东西时，你如何做呢？复制您的代码？
通过使用ORM，很容易从任何地方获取任何实体myOrm.Fetch< User>(user => user.Id == 1)修改它，然后保存它。这可以是相当方便，但也添加代码气味，因为你重复的代码，并无法控制如何创建对象，如果他们有一个有效的状态或正确的关联。
