求一种合适的设计模式解决这个问题求一种合适的设计模式解决这个问题think about PO carefully!when you u
求一种合适的设计模式解决这个问题
求一种合适的设计模式解决这个问题
think about PO carefully!
when you use patterns,don't do it like that. 15 楼 terry_yip 2007-03-14 谢谢上面的各位, 综合来说,我还是认同jerryfish的观点, 用decorator来解决这个问题, 虽然他的言语有点激动.
16 楼 wyork 2007-03-14 terry_yip 写道谢谢上面的各位, 综合来说,我还是认同jerryfish的观点, 用decorator来解决这个问题, 虽然他的言语有点激动.
能不能翻译一下？ 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;
}
}
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. 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? :-)).
