【发布时间】：2011-06-11 02:16:07
【问题描述】：
我有点好奇其他开发人员在使用 Entity Framework 或 NHibernate 在 ASP.NET MVC 中进行编程时应用存储库模式的经验。在我看来，这种模式已经在 ORM 本身中实现了。实体框架中的 DbContext 和 DbSet<T> 以及 NHibernate 中的 ISession。 Repository 模式中提到的大多数问题——在POEE 和DDD 中进行了分类——这些 ORM 都很好地实现了。也就是说，这些担忧是，
- 坚持
- 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 抽象。似乎在上述情况下使用存储库模式无非是开发人员自我强化和更多的排场和仪式，没有任何可实现的技术优势。你有什么想法？？
【问题讨论】：
-
我同意这里的观点（和I'm not the only one），但是“你的想法是什么”是一个主观和有争议的问题的定义。
-
"创建这些存储库实现是多余的" 那是因为他们做错了。存储库应该代表域概念，而不是通用的CRUD。
-
@Jeff - 就其本质而言，“软件模式”对上下文非常敏感，并且不像编程语言和平台那样通用。阅读此blog.plover.com/2006/09/11。因此，在讨论软件模式时，不可避免地会有某种程度的主观理由。
-
@qstarin - Repository 的软件模式规范声明
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.显然，Repository 模式的构思是为了抽象出数据访问问题，像 nHibernate 和 Entity Framework 这样的 ORM 做得非常好。在 DDD 中，域对象抽象域逻辑而不是存储库。这使得存储库模式变得多余。 -
据我所知，ORM 中缺少的存储库模式的主要有形好处是能够抽象依赖关系（测试）并将可重用查询保存在一个地方。在我看来，这些缺点可以而且应该由 ORM 设计者解决。事实上，在代码生成和扩展方法的部分类之间，我认为查询重用问题已经被实体框架解决了一些。
标签： asp.net-mvc design-patterns orm domain-driven-design