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

terry_yip

浏览: 38778 次

最近访客更多访客>>

jiruitong

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (9)

社区版块

存档分类

设计模式 DAO AOP Excel 数据结构

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

 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");
		 
                   if(!BACKUP.equals("1"))
                   {  
                       SpringDao.delete(vo);
                   }
                   else
                   {  
		     SpringBakDao.delete(vo, new String[]{user,actionType,projectUtils.getVOId(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");
		  if(!BACKUP.equals("1"))
                        SpringDao.insert(vo);
		  else
			SpringBakDao.insert(vo, new String[]{"Terry",actionType});
		}
		catch(Exception ex)
		{
			ex.printStackTrace();
			result=module+"_INSERT_FAIL";
		}
		log.info("GeneralPersistBO...INSERT()...result:"+result);
		return result;
	}

这是一个进行持久化事务的类,这里有两个DAO分属于不同类型,SpringDao只往一个数据库中存数据,SpringBakDao会往备份数据库中存数据,BACKUP常量控制是哪种持久化方式,问题是,每次crud操作时,
都对BACKUP判断一次, 实在是有冗余代码,不是一个良好的设计,我想到几个方案:

1 使 SpringDao和SpringBakDao都实现一个IDAO接口,但问题是,这两个DAO的crud方法,都是需传入不同的参数个数的,如果想统一起来,可以写一个Adapter,然后实现所有接口方法,再每个Dao继承这个Adapter并重载相关的方法,但是,由于要传入的参数个数不同, 始终要判断BACKUP的值

2 用proxy或interceptor, 都存在一个难点,不同DAO的相同的crud方法的参数都不一样的,就算同一个DAO类型的crud四个方法的参数个数也不一致,例如
SpringBakDao.delete(vo,new String[]{String id}),SpringBak.insert(vo,new String[]{String id,String newId}); 如果我用proxy模式,岂不是要传入最多的参数个数入这个proxy类里面,才能应付所有情况?

两种方案都不是理想的,所以想听听大家的意见,有什么更好的模式可以解决这个问题.谢谢

分享到：

关于XFire来做Web Service, 传入Service ... | spring事务管理的控制问题

2007-03-12 12:16
浏览 5283
评论(19)
论坛回复 / 浏览 (19 / 9604)
分类:企业架构
查看更多

19 楼 jellyfish 2007-03-16

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? :-)).

18 楼 jellyfish 2007-03-16

wyork 写道

terry_yip 写道

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

能不能翻译一下？

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.

17 楼 zrq 2007-03-16

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;
}
}

16 楼 wyork 2007-03-14

terry_yip 写道

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

能不能翻译一下？

15 楼 terry_yip 2007-03-14

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

14 楼 redhat 2007-03-14

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.

13 楼 wyork 2007-03-14

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

12 楼 wyork 2007-03-13

在初始化的时候定义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;   
}
}

11 楼 qinysong 2007-03-13

jellyfish说的很好

10 楼 jellyfish 2007-03-13

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.

9 楼 redhat 2007-03-12

Class
DeleteData // data to del
BakDeleteData //extends DeleteData to del as bak data
DataOperator //to operate data fuction/action
DeleteImpInterface //interface to perform delete action
DeleteBak //implements DeleteImpInterface to del bakeup database's data
DeleteNormally //implements DeleteImpInterface to del normal database's data

Test to test the function;

public class DeleteData
{
    protected Object vo;

    public DeleteData(Object obj)
    {
        this.vo = obj;
    }

    public Object getVo()
    {
        return vo;
    }

    public void setVo(Object vo)
    {
        this.vo = vo;
    }
}

{
    private String[] extParams;

    public BakDeleteData(Object obj){
        super(obj);
    }

    public void setExtParams(String[] extParams)
    {
        this.extParams = extParams;
    }

    public String[] getExtParams()
    {
        return extParams;
    }
}

public class DataOperator
{
    private static Logger log = Logger.getLogger("data/operator");
    private DeleteImpInterface deletor;

     public DataOperator( )
    {
    }
    public DataOperator(DeleteImpInterface deletor)
    {
        this.deletor = deletor;
    }

    public void setDeletor(DeleteImpInterface deletor)
    {
        this.deletor = deletor;
    }

    public DeleteImpInterface getDeletor()
    {
        return deletor;
    }

    public String onDelete(DeleteData obj)
    {
        // TODO Auto-generated method stub
        String result = "JOBTITLE_DELETE_SUCC";
        log.info("**********deleting*************");
        try {
//              Object vo=clientDataMap.get("DELETE_OBJECT");
//                   deldata=new DeleteData(obj);
            deletor.delete(obj);

//                 SpringBakDao.delete(vo, new String[]{user,actionType,projectUtils.getVOId(vo)});

        }
        catch (Exception ex) {
            ex.printStackTrace();
            result = "JOBTITLE_DELETE_FAIL";
        }
        return result;
    }
}

public interface DeleteImpInterface
{
    public void delete(DeleteData d) throws Exception;
}

public class DeleteBak implements DeleteImpInterface
{
    public void delete(BakDeleteData d)
    {
        SpringDao.delete(d.getVo(), d.getExtParams());//use SpringDao to imp,you must define this first.
    }

public class DeleteNormally implements DeleteImpInterface
{
    public void delete(DeleteData d)
    {
        SpringDao.delete(d.getVo());());//use SpringDao to imp,you must define this first.

    }
}
}

public class Test
{
    public static void main(String[] args)
    {
        //get po
        Object vo1 = new Object();//or get po by vo; use SpringDao.getPo(vo) or someone else;
        Object vo2 = new Object();//or get po by vo; use SpringDao.getPo(vo) or someone else;

        //get deleted data
        DeleteData delData1 = new DeleteData(vo1);
        BakDeleteData delData2 = new BakDeleteData(vo2);
        delData2.setExtParams(new String[]{"sss", "ddddd"});

        DataOperator operator = new DataOperator();

        //del normal database's data
        operator.setDeletor(new DeleteNormally());
        operator.onDelete(delData1);

        //del bakeup database's data
        operator.setDeletor(new DeleteBak());
        operator.onDelete(delData2);
        //http://www.iteye.com/topic/59239
    }
}

of course it is not perfect one for our purpose,
but yoou know ,there is no perfect one but the best! try for it,perhaps it is not very well!just try it.

firstly I just want to say that don't use too much params to pass to methods,encapsulate the for the best;we can modify them easily when params increased or decreased
secondly, use strategy or bridge.but you must know that,strategy is not the perfect one.maybe someone else
thirdly, use polymorphism to avoid if/else, that is an effective way.
have fun!

8 楼 xly_971223 2007-03-12

badqiu 写道： 
<div class='quote_div'>
使用Template Method
<div class='code_title'>java 代码</div>
<div class='dp-highlighter'>
<div class='bar'/>
<ol class='dp-j'>
 <li class='alt'>public String onDelete(Object obj) </li>
 <li class=''>{ </li>
 <li class='alt'> // TODO Auto-generated method stub </li>
 <li class=''> String result="JOBTITLE_DELETE_SUCC"; </li>
 <li class='alt'> log.info("**********deleting*************"); </li>
 <li class=''> try </li>
 <li class='alt'> { </li>
 <li class=''> Object vo=clientDataMap.get("DELETE_OBJECT"); </li>
 <li class='alt'> </li>
 <li class=''> if(!BACKUP.equals("1")) </li>
 <li class='alt'> { </li>
 <li class=''> delete(vo); </li>
 <li class='alt'> } </li>
 <li class=''> else </li>
 <li class='alt'> { </li>
 <li class=''> delete(vo, new String[]{user,actionType,projectUtils.getVOId(vo)}); </li>
 <li class='alt'> } </li>
 <li class=''> } </li>
 <li class='alt'> catch(Exception ex) </li>
 <li class=''> { </li>
 <li class='alt'> ex.printStackTrace(); </li>
 <li class=''> result="JOBTITLE_DELETE_FAIL"; </li>
 <li class='alt'> } </li>
 <li class=''> return result; </li>
 <li class='alt'>} </li>
 <li class=''> </li>
 <li class='alt'>protected void delete(Object vo) {} </li>
 <li class=''>protected void delete(Object vo,String[] args){}; </li>
 <li class='alt'> </li>
 <li class=''>public String onInsert(Object obj) </li>
 <li class='alt'>{ </li>
 <li class=''> String result=module+"_INSERT_SUCC";; </li>
 <li class='alt'> try </li>
 <li class=''> { </li>
 <li class='alt'> Object vo=clientDataMap.get("VO"); </li>
 <li class=''> if(!BACKUP.equals("1")) </li>
 <li class='alt'> insert(vo); </li>
 <li class=''> else </li>
 <li class='alt'> insert(vo, new String[]{"Terry",actionType}); </li>
 <li class=''> } </li>
 <li class='alt'> catch(Exception ex) </li>
 <li class=''> { </li>
 <li class='alt'> ex.printStackTrace(); </li>
 <li class=''> result=module+"_INSERT_FAIL"; </li>
 <li class='alt'> } </li>
 <li class=''> log.info("GeneralPersistBO...INSERT()...result:"+result); </li>
 <li class='alt'> return result; </li>
 <li class=''>} </li>
 <li class='alt'> </li>
 <li class=''>protected void insert(Object vo) {} </li>
 <li class='alt'>protected void insert(Object vo,String[] args){}; </li>
</ol>
</div>
</div>
 
 
模版方法是不能解决重复代码的。想象一下如果有10个onXXX（）方法都带有
if(!BACKUP.equals("1")) 
<li class='alt'> { </li>
<li class=''> SpringDao.delete(vo); </li>
<li class='alt'> } </li>
<li class=''> else </li>
<li class='alt'> { </li>
<li class=''> SpringBakDao.delete(vo, new String[]{user,actionType,projectUtils.getVOId(vo)}); </li>
<li class=''>}</li>
是不是很白痴而且如果需求有改变，需要加一个else if ，难道要修改这10个方法吗？

7 楼 badqiu 2007-03-12

使用Template Method
<div class='code_title'>java 代码</div>
<div class='dp-highlighter'>
<div class='bar'/>
<ol class='dp-j'>
 <li class='alt'>public String onDelete(Object obj) </li>
 <li class=''>{ </li>
 <li class='alt'> // TODO Auto-generated method stub </li>
 <li class=''> String result="JOBTITLE_DELETE_SUCC"; </li>
 <li class='alt'> log.info("**********deleting*************"); </li>
 <li class=''> try </li>
 <li class='alt'> { </li>
 <li class=''> Object vo=clientDataMap.get("DELETE_OBJECT"); </li>
 <li class='alt'> </li>
 <li class=''> if(!BACKUP.equals("1")) </li>
 <li class='alt'> { </li>
 <li class=''> delete(vo); </li>
 <li class='alt'> } </li>
 <li class=''> else </li>
 <li class='alt'> { </li>
 <li class=''> delete(vo, new String[]{user,actionType,projectUtils.getVOId(vo)}); </li>
 <li class='alt'> } </li>
 <li class=''> } </li>
 <li class='alt'> catch(Exception ex) </li>
 <li class=''> { </li>
 <li class='alt'> ex.printStackTrace(); </li>
 <li class=''> result="JOBTITLE_DELETE_FAIL"; </li>
 <li class='alt'> } </li>
 <li class=''> return result; </li>
 <li class='alt'>} </li>
 <li class=''> </li>
 <li class='alt'>protected void delete(Object vo) {} </li>
 <li class=''>protected void delete(Object vo,String[] args){}; </li>
 <li class='alt'> </li>
 <li class=''>public String onInsert(Object obj) </li>
 <li class='alt'>{ </li>
 <li class=''> String result=module+"_INSERT_SUCC";; </li>
 <li class='alt'> try </li>
 <li class=''> { </li>
 <li class='alt'> Object vo=clientDataMap.get("VO"); </li>
 <li class=''> if(!BACKUP.equals("1")) </li>
 <li class='alt'> insert(vo); </li>
 <li class=''> else </li>
 <li class='alt'> insert(vo, new String[]{"Terry",actionType}); </li>
 <li class=''> } </li>
 <li class='alt'> catch(Exception ex) </li>
 <li class=''> { </li>
 <li class='alt'> ex.printStackTrace(); </li>
 <li class=''> result=module+"_INSERT_FAIL"; </li>
 <li class='alt'> } </li>
 <li class=''> log.info("GeneralPersistBO...INSERT()...result:"+result); </li>
 <li class='alt'> return result; </li>
 <li class=''>} </li>
 <li class='alt'> </li>
 <li class=''>protected void insert(Object vo) {} </li>
 <li class='alt'>protected void insert(Object vo,String[] args){}; </li>
</ol>
</div>

6 楼生命火花 2007-03-12

多态可以解决它的问题吗？好像只会增加复杂度！

接口不定啊！如果用多态，要写很多child！

5 楼 xly_971223 2007-03-12

两个方法的重复代码结构都一样如下

if(!BACKUP.equals("1"))   
                  {     
                      SpringDao.delete(vo);   
                  }   
                  else  
                  {     
         SpringBakDao.delete(vo, new String[]{user,actionType,projectUtils.getVOId(vo)});   
           }

很明显这是一种多态。

解决方法：
interface Dao {
onDelete(...);
onInsert(...);
}
SpringDao implements Dao
SpringBakDao implements Dao
在Dao的上层去确定要调用SpringDao 或 SpringBakDao

这个问题是典型的用多态代替状态码的重构

4 楼 ahau205109 2007-03-12

springdao extends basedao
    onDelete(do your work)
    oninsert(do your work)
    datasource:real system datasource
backdao extends basedao
    onDelete(do your work)
    oninsert(do your work)
    datasource:baackup system datasource
daoHelper:
    getDao() due to your system;
client:
    daoHelper.getDao.oninsert(...);

3 楼生命火花 2007-03-12

引用

2 用proxy或interceptor, 都存在一个难点,不同DAO的相同的crud方法的参数都不一样的,就算同一个DAO类型的crud四个方法的参数个数也不一致,例如
SpringBakDao.delete(vo,new String[]{String id}),SpringBak.insert(vo,new String[]{String id,String newId}); 如果我用proxy模式,岂不是要传入最多的参数个数入这个proxy类里面,才能应付所有情况?

诚然，你自己已经知道问题的所在了！这个是个不可调和的问题！

你不封装参数提供统一接口就不能利用Aop去解决问题！

其实这就是个取舍！

不清楚你的这些操作到底有多少，但是理想设计上考虑应该包起来。不过到底有没有这个必要你自己要酌情考虑

但是写Adapter到这个地步是不是太晚了，不能再在Dao上做文章了，只能动Proxy!

2 楼 terry_yip 2007-03-12

AOP和proxy是同样的道理, 不方便的地方,我上面提过了.

1 楼 XMLDB 2007-03-12

这种场景比较适合用AOP.

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论