哪种设计模式更适合保存/删除数据？为什么？

Question

我无法在以下两种模式之间做出决定，例如。保存一个数据对象（在我的例子中是bean）。这两个选项是：

1st

abstract class DataService {
    protected void save(Object data){
        //persist the data
    }
}
//the service for Project objects
class ProjectService extends DataService {
    public void saveProject(Project prj, Object... args /*other save options*/ ){
        // some preprocessing, checking, validation
        save(prj); //call the method in DataService
        // do postprocessing
    }
}

//calling save
projectService.saveProjec(project, /*some args*/);

2nd

abstract class DataService {
    public void save(Object data){
        if(beforeSave(data)){
            // persist the data
            afterSave(data);
        }
    }
    protected boolean beforeSave(){
        return true;
    }
    protected void afterSave(){
    }
}

//the service for Project objects
class ProjectService extends DataService {
    public initSave(Object... args /*other save options*/ ){
        // store these options in class properties
    }
    @Override
    protected bool beforeSave(Project objectAboutToBeSaved){
        // some preprocessing, checking, validation
        // use class properties set by initSave if needed
        return true;//if we want to continue with the saving procedure
    }

    @Override
    protected bool afterSave(Project savedObject){
        // do postprocessing
        // use class properties set by initSave if needed
    }
}

//calling save
projectService.initSave(/*some args*/);
projectService.save(project);

目前我们正在使用第一种模式，但我开始考虑转向第二种模式，因为：（

优点）

• 逻辑更好 跨多个对象类型的分离
• 统一方法命名（将允许创建通用单元测试：例如初始化每个对象及其服务并调用保存）

（缺点）

• 设置起来有点困难（initSave） - 甚至可能必须包括拆卸

方法我的想法来自CakePHP MVC框架，其中Model和Controller都包含了这样的回调方法，使用它我可以真正实现一些清晰的业务逻辑。

现在我正在 Java 中开发 - Spring + Spring Data Graph -（因此 javaish代码），但在我看来，这个问题可能是一个非常普遍的问题。

注意：给出的示例是保存过程，但删除过程也是如此。

Answer 1

另一种解决方案是使用策略模式并执行如下操作。
我们使用这种方法进行预持久验证，有时甚至计算（基于其他字段）并设置要持久保存的数据对象的某些字段（例如，我们有一个基于其他字段更新的“完整”标志）每当持久化或更新我们的实体之一时的字段）。

您的策略：

interface SaveStrategy<T> {
  boolean beforeSave(T data);
  void afterSave(T data);
}

class SomeFancyProjectSaveStrategy implements SaveStrategy<Project> {

  public SomeFancyProjectSaveStrategy( /*parameters*/) {
  } 

  public boolean beforeSave(Project data) {
     //whatever you like
  }

  public void afterSave(Project data) {
     //whatever you like
  }
}

您的数据服务：

class DataService {
  public <T> void save(T data, SaveStrategy<? super T> strategy ){
    if(strategy.beforeSave(data)){
        // persist the data
        strategy.afterSave(data);
    }
  }
}

然后像这样使用它们：

SaveStrategy<Project> saveStrategy = new SomeFancyProjectSaveStrategy(someParameters); //could reuse that
dataService.save( project, saveStrategy); //the service might even be shared for different data objects

优点：

• 保存前和保存后操作与持久化分开
• 您可以重复使用策略，只要它们包含可重用数据（例如验证规则，但没有状态）。
• 您可以使用通用的 DataService

缺点

• 如果您需要特殊的保存逻辑，您可能必须维护至少两个类：策略和特殊数据服务

Answer 2

我也不会说。对我来说，两者看起来都不必要地复杂。

一个简单的 CRUD 接口应该做的事情：

public interface GenericRepository<K extends Serializable, T> {
    Collection<T> find();
    T find(K id);
    K save(T value);
    void update(T value);
    void delete(T value);
}

所有验证和检查都应该在到达持久层之前完成。我认为这违反了单一责任原则。

交易属于服务层。持久层无法知道它是否被要求参与事务。如果还有其他人怎么办？

你们的想法都过于复杂。我都会拒绝。

Answer 3

我更喜欢第二个。

主要区别在于它告诉类的用户应该如何使用它。这是一个很大的优点（更明显）和一个小的缺点（灵活性较差）。另外，第二种方法允许更好地扩展子类（ProjectService 的子类可以重用 before() 方法并扩展 after() ）。要记住的一件事是，子类实际上可以丢弃其中一个方法（通过覆盖它而不是在超类中调用它）。如果允许或不允许，请务必记录每个子类。

Answer 4

第一个示例更简单。如果您需要批量处理数据，第二个示例会更好。即开始/结束更新的开销很重要。

您仍然可以通过使用线程本地状态来使第二个示例线程安全。

您可以两全其美。

bool beforeSave(Project objectAboutToBeSaved);
void saveProject(Project prj, Object... args /*other save options*/ );
bool afterSave(Project savedObject);

这可以用于两种模式。

void saveProject(Project prj, Object... args /*other save options*/ ) {
    boolean inBatch = inBatch(prj);
    if (!inBatch) beforeSave(prj);

    saveProject0(prj, args);

    if (!inBatch) afterSave(prj);
}

这允许您混合和匹配并拥有一些执行单个更新的方法，但从某些方法调用时将隐式批处理保存的数据。