caching - 双重用途类的设计模式(内存缓存或表)

Question

我需要在数据源上实现 CRUD 操作，该数据源可以是物理表或逻辑(内存缓存在查询多个表后保存数据)。数据源的理想选择是数据库中的表。但由于某些原因，存在内存缓存类模仿理想实现的替代实现。

interface IEmp
{
      Add();
      Update();
      Remove();
}

有2个实现:

1. Emp 类

在sqlite中的物理表上操作

EmpCache 类

操作内存缓存 - 聚合来自多个其他表的数据

基于性能或其他非功能性需求，该类消费者可以选择切换到两个选项之一。

我正在考虑在这里应用设计模式，这样就不会造成太多返工。

我看到这里有两种适用的设计模式:

a.策略模式 -

接口(interface) IEmp 将有 2 个单独的实现(如上所述)。例如

Class EmpTable
{
     IEmp table;
     bool isInMemory;
}

基于 isInMemory T/F table 会将底层实例切换到上述实现之一 {Emp 或 EmpCache}

b.装饰器模式 - 另一个接口(interface)扩展+封装 IEmp 接口(interface)。并根据属性变化 - 它将酌情采取行动/委托(delegate)例如

IEmpCache : IEmp
{
     IEmp instance;
     bool useCache;
}
EmpCache : IEmpCache
{
     Add()
     {
         if(!useCache)
         {
             instance.Add();
         }
         //cache logic
     }
     ... // same for all other methods
}

我认为方法b更好，但主要在需要添加/增强已发布的功能(类/接口(interface))时使用，不是吗？

哪个更好？还有其他更好的模式吗？

Answer 1

当然选择B更好。

我们首先看一下以下模式是如何分类的。装饰器是一种结构模式，策略是一种行为模式。

Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.

根据您的问题，您希望向现有对象添加新行为。装饰器的定义就像你描述你的问题一样。缓存是您要添加的新行为。我在类似的问题中使用过它，通常效果很好。它适用于无法更改的类或有一天可能需要缓存的新功能。

Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.

我没有使用策略来缓存数据。根据定义，我认为它有不同的目的。使用已经发布的类来实现可能会更困难。该策略有很多用例，例如，当您进行一些可能会发生变化的计算时，它可能会更好。

我在使用数据库时使用了策略模式，但在这种情况下我想支持许多不同的复杂查询。这样，我就可以使用策略模式实现查询，并将该策略传递给处理数据库连接的对象。