实现不同存储策略的模式答案

【问题标题】：Pattern to implement different storage strategies实现不同存储策略的模式
【发布时间】：2014-06-16 08:13:56
【问题描述】：

我将实现 Data Mapper 模式以将数据存储在不同的存储/数据库中。

实现这个概念的最佳 OOP 模式是什么？

比如我有User模型类

public class User 
{
  private int id;
  private String name;
  private String surname;

  /* getters, setters and model-level business logic  */
}

和适当的数据映射器类

public class UserMapper
{
  public User findById(int id)
  {
    // perform query to MySQL, Redis or another DB
  }

  /* other methods */
}

通过创建多个存储策略类然后将它们注入 DataMapper 类来使用 Strategy 模式是不是一个好主意？

 public class UserMySQLStorageStrategy extends UserStorageStrategy
 {
   public User findById(int id)
   {
     // perform query to MySQL
   }
 }

 public class UserRedisStorageStrategy extends UserStorageStrategy
 {
   public User findById(int id)
   {
     // perform query to Redis
   }
 }

public class UserMapper
{
  protected UserStorageStrategy _storageStrategy;

  public UserMapper(UserStorageStrategy storageStrategy)
  {
    this._storageStrategy = storageStrategy;
  }


  public User findById(int id)
  {
    return this._storageStrategy.findById(id);
  }

  /* other methods */
}

【问题讨论】：

只是一个警告 - 在您的问题中使用“最佳”可能会吸引“主要基于意见”的密切投票
@user3580294 感谢您的注意 :)
对我来说似乎很好。我会称它为 UserDAO 而不是 UserMapper

标签： java design-patterns

【解决方案1】：

您的策略看起来非常像映射器类本身。相反，将您的映射器和用户对象变成接口可能是有意义的，然后您的特定实现选择存储它们的方式/位置。如果您的 UserMapper 类执行许多与存储无关的操作并且尽管存储不同但不需要更改，则该策略方法是有意义的；但是如果你的 UserMapper 类所做的只是存储，那么一个接口和多个实现会更简单。

【讨论】：

是的，我明白了，所以在您回答之前我刚刚删除了我的 cmets。 :)
在你描述的策略方法案例中（如果有很多与存储无关的操作），是否可以将这些与存储无关的功能带到基类中？
@zavg 最好使用组合/委托而不是继承。因此，如果有许多与存储无关的操作，那么您最初提供策略的方法会更有意义。

【解决方案2】：

您不需要任何特定的 OOP 设计模式。您需要的是提供功能的接口。

那么你的不同数据存储应该实现它。然后你只需要一个为你的程序工作流提供预期实例的策略。

【讨论】：

【解决方案3】：

我首先将UserMapper 设为一个具有多个实现具体类的接口，然后调用接口UserDao。

我将调用实现类User{Mysql|Redis|etc}DAO。如果您发现它们之间有任何共同的代码，可以将其提取到一个共同的抽象基类中。

此时UserMapper 类的逻辑可以被调用到UserDaoResolver，它根据一些输入选择并返回具体实现，或者如果您使用一些依赖注入框架（如 Spring），您可以将该函数委托给它.

当前UserMapper调用者将通过其接口使用DAO实现，并通过上述方法之一获取。

【讨论】：