我的BO之导航属性
我的BO
1-我的BO之强类型
2-我的BO之数据保护
3-我的BO之状态控制
4-我的BO之导航属性
数据需要导航
数据之间普遍存在关系,做业务处理时往往也是按照关系在数据之间查询和处理。业务处理可看作是各种检查和计算后,保存结果。而检查和计算往往意味着要查数据A,以及数据A相关的数据B,数据B相关的数据C……。
BO 与数据表相对应。一个 BO 类对应一个数据表,一个 BO 对象对应数据表中的一条记录。表间的关系,也是 BO 间的关系。典型的是一对多关系。比如 “买家-订单-订单明细”三者的关系是:一个买家可以拥有多个订单,一个订单对应多个订单明细;反过来,一个订单明细对应一个订单,一个订单对应一个买家。订单是买家的子对象,买家是订单的父对象。
当得到一个订单 BO 时,希望可以通过它的属性得到它的明细,明细是一个 BO 集合,希望可以通过它的另一个属性得到它的买家 BO。同理,当得到一个订单明细 BO,希望可以通过它的一个属性得到它的订单 BO。
通过 BO 的属性获取到另一个 BO 或 BO 的集合,这种属性叫做 BO 的导航属性。
对null值的处理
当父对象可能为null
时,导航到父对象的属性有两个,一个是Xxx
,另一个是XxxOrNull
。比如一个学生一般是对应一个班级,但如果业务逻辑允许新生报到时暂未分配到班级,学生的班级属性就可能为null
。为了准确地处理null
值的问题,学生的班级对应两个属性:Class
和ClassOrNull
。并规定,Class
这个属性不返回null
,学生当前没有对应班级时,则抛异常
,如果希望返回null
而非抛异常
,则使用ClassOrNull
。当父对象不允许为null
时,则不提供XxxOrNull
属性。
子对象一般表现为父对象的一个集合属性,若一个对象的子对象数量为零,则规定返回空(Empty)集合,而不是null
。
class 班级Bo extends BoBase {
public List<学生Bo> get学生List() {
Long id = this.getId();
return boProvider.list学生By班级Id(id); // 见说明1
}
}
class 学生Bo extends BoBase {
public 班级Bo get班级() {
Long 班级Id = this.get班级Id();
return boProvider.get班级(班级Id);
}
public 班级Bo get班级OrNull() {
if (this.get班级Id() == null)
return null;
return this.get班级(); // 见说明2
}
}
说明:
-
boProvider
是BoBase
的属性,一切的 BO 对象都由boProvider
产生。 - 如果
班级Id
不是null
,却在数据库中找不到该班级数据,则还是会抛异常,也应该抛异常。 - 为了便于说明且不影响道理的表达,这里使用了中文命名,实际项目中并非如此。
优点
- 导航属性让使用者方便地得到 BO 对象的相关对象,屏蔽了内部关系的细节,使用方便。
- 导航属性包含了找不到时返回
null
还是抛异常
的逻辑,避免了到处编写重复的代码,减少了对null
值的处理不当导致空引用异常
的风险。 - 效果:只要得到一个 BO 对象,就可以得到与它相关的全部对象,使业务逻辑代码简洁、安全、灵活。
展望
目前的导航属性是只读的,这点不够面对对象(OO),只是因为实现起来简单。未来若有需要,可以提供修改导航属性同时修改关系的功能,用起来更加OO,可能有一些复杂的技术细节问题要解决。
目前通过导航属性获取(BO)对象,每次都从数据库装载,一定概率下会产生多余的查询。解决方法是在内存中统一缓存,通过ID判断若内存已有则不到数据库中取。这个方案一方面会增加一点内存开销,同时为了满足“就算内存中有,也要到数据库装载”的需求,需要设计复杂一点的机制。还需要解决前面的业务修改了的对象,后面的业务(同一个请求)获取是否应该获取修改后的这个对象版本的问题,我目前觉得应该获取修改后的版本,而不是数据库中那个。无论获取到的是哪个版本,会不会在业务处理上造成Bug,有待进一步研究。