求一种合适的设计模式解决这个问题

too many problems, nothing is right, a piece of junk.

1. never pass Object type on the DAO interface. DAO interface is part of domain, you should use strong typed classes from your domain.
2. DAO serves the purpose of persistence, and thus the DAO interface should be designed independent of underlying persistence, be database, file, etc. So you should really consider hard *what* you want to persist and pass that in.
3. Proxy pattern is totally irrelevent. Interceptor is not right either. The correct pattern is the Decorator. What pattern to use is determined by your purpose, not behavior. Your purpose is to shield out the persistent complexity from the caller of the DAO interface, not you want vary the implementation(not proxy), and maintain the same interface(not interceptor). AOP is equiv~ to the Decorator(i.e., maintain the DAO interface).

Fix the DAO interface first, then use decorator.
Think about the DAO interface if you need to save the data to a file, a db, an excel table, then you can abstract something out.

Think about decorator to add a backup logic, a cache, a permission check, etc. Then you can separate different responsibilities.

My word may be harsh, not to you, but to the code. You have to see through the details to get the bottom. Abstraction is the golden rule.

Cheers.

jellyfish说的很好

在初始化的时候定义Dao呢？

public class class_name {

//Object可以是SpringDao和SpringBakDao的接口
private Object dao = new Object();
public class_name(){    
    if(!BACKUP.equals("1"))   
    {     
        dao = new SpringDao();   
    }   
    else  
    {     
        dao = new SpringBakDao();   
    }   

}
public String onDelete(Object obj)   
{   
    // TODO Auto-generated method stub   
    String result="JOBTITLE_DELETE_SUCC";   
    log.info("**********deleting*************");   
    try  
    {    
      Object vo=clientDataMap.get("DELETE_OBJECT");   
      dao.delete(vo);   
    }   
    catch(Exception ex)   
    {   
        ex.printStackTrace();   
        result="JOBTITLE_DELETE_FAIL";   
    }   
    return result;   
}   
  
public String onInsert(Object obj)   
{      
    String result=module+"_INSERT_SUCC";;   
    try  
    {    
      Object vo=clientDataMap.get("VO");   
      dao.insert(vo);   
    }   
    catch(Exception ex)   
    {   
        ex.printStackTrace();   
        result=module+"_INSERT_FAIL";   
    }   
    log.info("GeneralPersistBO...INSERT()...result:"+result);   
    return result;   
}
}  

这个帖子对你有帮助
http://www.iteye.com/post/236928

just think about the context!

jellyfish,get the point firstly!

don't consider contest,problem,and solution seperately!

just get the point!don't be distracted by the code.

think encapsulation over,don't say never.
"never pass Object" !
think about PO carefully!

when you use patterns,don't do it like that. 

谢谢上面的各位, 综合来说,我还是认同jerryfish的观点, 用decorator来解决这个问题, 虽然他的言语有点激动.

能不能翻译一下？

The purpose of the code is to backup the data in another database if the flag is true.

The solution itself is not correct if there are some buik deletion and bulk update, while only trigger could be used to track the data changes.

If your case doesn't have any bulk update and bulk deletion.The backup dao and regular dao should implement the same interface. In the business logic, get the dao from DaoFactory, in which you can decide which dao should be returned,and after that you you should be able to any update/delete.

If the backupDAO does need more paramters that the regular dao ,while in normal cases it should not, the extra parameters could be passed in as the parameter when retrieving the dao from daofactory, where the parater could be ingored if the returned dao is regular dao.

Here is the psudo code to simplify your code.


//you business object;
  IDAO dao=Daofactory.getDAO(user,actionType);
  dao.onDelete(vo);
 

class Daofactory{
   public static IDAO getDAO(User user,String actionType){
   IDAO dao=null;
    if(!BACKUP.equals("1")) {
      dao=new RegularDAO();
    }else{
      dao=new BackDAO( user, actionType);
    }
    return dao;
   }

}

interface IDAO {
public onDelete(Object vo);
public onUpdate(Object vo);
}

public class BackDAO implements  IDAO{

private User user;
private String actionType;


public BackDAO(User user,String actionType){
this.user=user;
this.actionType=actionType;
}

public onDelete(Object vo){
//TODO: your own  backup logic
}
public onUpdate(Object vo){
//TODO: your own backup logic;
}

}



public class RegularDAO implements  IDAO{



public onDelete(Object vo){
//TODO: your own  backup logic
}
public onUpdate(Object vo){
//TODO: your own backup logic;
}
}

he tend to agree with jellyfish(not jerryfish, it's the stinky jellyfish, my daughter's favorite, :-)) saying, though jellyfish is nowhere close to be gentle.

backup is part of the persistent strategy, so it should be hidden under the DAO as well, this means in the business object, there is only one DAO for this. Again decorate the normal persistence with another backup function.

Shielding out the persistence doesn't make much difference for smaller, stable projects(which are the idea playground that RoR folks are battling on), but it makes big difference in complex or large projects where new functionalities are added almost daily. Though due to heavy impact on performance DAO shows more in discussions, this is not the only component, other services, especially distributed services, can also make big impact as well.

My word was harsh because I felt this was not in the right direction. I raised a bright red flag to say, hey, that's not the direction you want to go(do I sound like a dictator? :-)).