易于实现的仓储模式实现

22 浏览
0 Comments

易于实现的仓储模式实现

我正在直接使用ADO.NET与MVC 5,而不是使用Entity Framework。\n我参考了这个示例来实现Repository模式。\n简单实现Repository模式的步骤如下:\n

    \n

  1. 我将创建一个模型
  2. \n

  3. 我将创建一个包含CRUD方法声明的接口
  4. \n

  5. 我将在数据访问层中创建一个类,该类将实现上述接口并具有CRUD方法的实现
  6. \n

\n我想知道为什么要使用接口?我不能直接使用一个类吗,就像上面的第三点所描述的那样。\n接口的角色是什么?\n根据上述三点,这是Repository模式的正确实现吗?

0
0 Comments

问题的出现原因是该教程中的示例实现过于简单,只是对EF的DbSet进行了封装,没有考虑到领域需求。通常,使用仓储模式需要根据领域需求设计一个合适的接口,至少包含添加(Add)、获取(Get)和保存(Save)三个方法。但是一切都取决于领域,这很重要:没有固定的规则,只取决于应用程序的需求。

仓储模式的实现仅涉及整个业务对象(业务概念)的持久化/加载(其中业务对象是一种业务概念)。你选择了使用Ado.net与数据库通信(其实应该选择一个微型ORM,因为使用Ado.net没有任何好处)。可以,只需实现与数据库的保存和查询过程。

没有关于如何实现仓储的固定规则。"难"的部分在于设计接口。实现只是一个使用数据库的类(以你想要的任何方式)。

我们使用接口,因为通常情况下,仓库接口是领域的一部分,而其实现是持久化的一部分。这也允许多个仓库实现和易于测试(通过模拟)。

顺便说一下,你必须理解仓储模式只是一个简单的原则。它可以以任何你想要的方式实现,没有"正确"的方式。但是,需要"正确"的是接口设计,只能使用业务对象,不能泄露实现细节(如IQueryable)。

0
0 Comments

问题的出现原因:有时候在处理插入逻辑时,我们可能需要通过队列传递,而不是直接传递给服务器,等待插入操作完成后再返回结果。这时,我们需要在不破坏原有代码的情况下实现这个功能。

解决方法:我们可以通过实现另一个类来实现这个功能,这个类具有相同的接口。这样,我们就可以在不破坏原有代码的情况下实现插入逻辑通过队列传递的功能。

做法如下:

1. 创建一个实现接口 IFoodEstablishmentService 的类 FoodEstablishmentQueueService。

2. 在 FoodEstablishmentQueueService 类中实现插入逻辑通过队列传递的功能。

3. 在使用这个功能时,只需要将原来的类 FoodEstablishmentService 替换为新的类 FoodEstablishmentQueueService。

以下是具体代码示例:

public class FoodEstablishmentQueueService : IFoodEstablishmentService
{
    public async Task AddAsync(FoodEstablishment oFoodEstablishment)
    {
        // 插入队列操作
        return result;
    }
    public async Task UpdateAsync(FoodEstablishment oFoodEstablishment)
    {
        // 更新队列逻辑
        return result;
    }
}

使用示例:

IFoodEstablishmentService oFoodEstablishmentService = new FoodEstablishmentQueueService();
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

这样就可以很方便地实现插入逻辑通过队列传递的功能,而且不会破坏原有代码。另外,使用 DI 容器可以更好地管理依赖关系。

在开发过程中,我们可以先选择一个简单的模式进行实现,当需要更多功能时再逐渐引入更适合的模式。对于大规模应用程序来说,仅使用存储库模式或通用存储库模式可能不是理想的选择,可能需要考虑使用 CQRS 模式。

0
0 Comments

在良好设计的代码中,你需要使用接口而不是具体实现。这样做有很多好处。想象一下你有一个带有以下代码片段的类:

IBookRepository bookRepository;
public Book GetInterestingBook() {
  var book = bookRepository.getBooks().FirstOrDefault(x => x.IsInteresting);
  return book;
}

现在我会向你展示一些好处:

  1. 使用接口可以通过依赖注入(Ninject、Unity等)隐式地创建bookRepository实例。如果你决定将存储库的实现从Entity Framework更改为NHibernate,你不需要对代码进行任何更改。只需在映射文件中更改映射以使用NHibernateRepository替代EFBookRepository。当然,NHibernateRepository也需要进行开发。
  2. 使用接口可以通过Mock对象实现出色的单元测试。你只需要实现MockBookRepository并在注入时使用它。有许多Mock框架可以帮助你,例如Moq。
  3. 你可以动态切换存储库而不更改代码。例如,如果你的数据库暂时不可用,但你有另一个可以处理新订单的数据库,因为它们是关键的(不是很好的例子,我知道)。在这种情况下,你可以检测到数据库故障并执行以下操作:

    currentRepository = temporaryOrdersOnlyRepository;

现在你的代码可以继续正常工作,只是你的获取数据和删除方法会返回异常,但CreateNewOrder()方法将把订单保存到字符串文件中。

祝你好运!

0