asp.net-mvc - 在使用 ASP.NET MVC 和 ORM 解决方案时，我们是否需要使用存储库模式？

Question

我有点好奇其他开发人员在使用 Entity Framework 或 NHibernate 在 ASP.NET MVC 中编程时应用存储库模式的经验。在我看来，这种模式已经在 ORM 本身中实现了。 DbContext 和 DbSet<T> 在 Entity Framework 中并由 ISession 在 NHibernate 中。 中提到的大多数问题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. 
}

Entity Framework :

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 或 Entity Framework )时，创建这些存储库实现是多余的。此外，由于这些模式实现不超过 ORMS 中已有的功能，因此它们更像 噪音 比有用的 OO 抽象。似乎在上述情况下使用存储库模式无非是开发人员的自我膨胀和更多的浮华和仪式，没有任何可实现的技术优势。你怎么认为 ？？

Answer 1

答案是没有如果您不需要能够切换 ORM 或能够测试任何依赖于您的 ORM/数据库的类。

如果您希望能够切换 ORM 或能够轻松测试使用数据库层的类:是的，您需要一个存储库(带有接口(interface)规范)。

如果您使用存储库模式，您还可以切换到内存存储库(我在单元测试中这样做)、XML 文件或其他任何内容。

更新

您可以通过谷歌搜索找到的大多数存储库模式实现的问题是它们在生产中运行不佳。他们缺乏限制结果(分页)和排序结果的选项，这真是太棒了。

当它与 UnitOfWork 实现结合并支持规范模式时，存储库模式就大放异彩了。

如果您发现有所有这些，请告诉我:)(我确实有自己的，但工作良好的规范部分除外)

更新 2

存储库不仅仅是以抽象的方式访问数据库，例如可以由 ORM 完成的。一个普通的 Repository 实现应该处理所有的聚合实体(例如 Order 和 OrderLine )。在同一个存储库类中处理它们时，您始终可以确保它们构建正确。

但是，嘿，你说:这是由 ORM 自动为我完成的。嗯，是的，也不是。如果您创建一个网站，您很可能只想编辑一个订单行。您是否获取完整的订单，遍历它以找到订单，然后将其添加到 View 中？

通过这样做，您将向 Controller 引入不属于那里的逻辑。当一个网络服务想要同样的东西时，你怎么做？复制你的代码？

通过使用 ORM，可以很容易地从任何地方获取任何实体 myOrm.Fetch<User>(user => user.Id == 1)修改它然后保存它。这可能非常方便，但也会添加代码异味，因为您复制代码并且无法控制对象的创建方式，如果它们具有有效的状态或正确的关联。

接下来想到的是，您可能希望能够以集中方式订阅 Created、Updated 和 Deleted 等事件。如果您有存储库，这很容易。

对我来说，ORM 提供了一种将类映射到表的方法，仅此而已。我仍然喜欢将它们包装在存储库中以控制它们并获得单点修改。