| |
在设计模式3中我们看到使bean从struct继承后使得代码大幅缩水并且所有的字段都可定义为cmp字段。这里，我们可以更进一步修正setdata()和getdata()的实现方法来减少代码量。
我们为这个struct增加一个方法。
value object code snippet for company
public class companystruct implements
java.io.serializable {
public integer comid;
public string comname;
public string comdescription;
public timestamp mutationdate;
public void copyfrom(companystruct struct) {
comid = struct.comid;
comname = struct.comname;
comdescription = struct.comdescription;
mutationdate = struct.mutationdate;
}
}
由于entity bean是从struct继承下来的，在bean的实现类中也一样可以引用copyfrom()方法，当然，必须注意的是，这个copyfrom()方法并不是一个商业方法，它不需要在bean的远程接口中暴露给调用者。
现在，getdata()和setdata()方法可以简化更进一步的简化。
code snippet for an entity bean’s getdata()
public companystruct getdata() {
companystruct result = new companystruct();
result.copyfrom(this);
return result;
}
这里把this作为一个参数传入copyfrom()。由于enttity bean从struct继承而来，于是这个entitty bean便可以作为一个struct传入。
ejb容器并不赞成把this指针作为一个参数传递因为在两个控制线程中同时访问一个bean的实例可能会引起事务冲突。但事实上我们所做的并没有违背这个原则，因为我们的并没有在bean之间传递this的引用并且也没有引用任何可能引起事务冲突的方法。
code snippet for an entity bean’s setdata()
public void setdata(companystruct struct) {
this.copyfrom(struct);
}
对于一个映射到有很多列的表的entity bean，这种实现方法的优点是使得bean实现类的代码非常简单。这种设计模式使得代码及其精简，可读性和可维护性也大大增强。任何数据库的修改都只需要修改作为基类的struct，而几乎不需要修改bean的代码。把这种改变从struct分离出来，当cmp字段发生改变时需要修改部署描述符。这就使得开发时能够更好的适应设计的改变。
这里，还是没有实现bean之间的关系，这将在设计模式5中解决。
|
|
