我的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
    }
}

说明：

1. boProvider是BoBase的属性，一切的 BO 对象都由boProvider产生。
2. 如果班级Id不是null，却在数据库中找不到该班级数据，则还是会抛异常，也应该抛异常。
3. 为了便于说明且不影响道理的表达，这里使用了中文命名，实际项目中并非如此。

优点

• 导航属性让使用者方便地得到 BO 对象的相关对象，屏蔽了内部关系的细节，使用方便。
• 导航属性包含了找不到时返回null还是抛异常的逻辑，避免了到处编写重复的代码，减少了对null值的处理不当导致空引用异常的风险。
• 效果：只要得到一个 BO 对象，就可以得到与它相关的全部对象，使业务逻辑代码简洁、安全、灵活。

展望

目前的导航属性是只读的，这点不够面向对象(OO)，只是因为实现起来简单。未来若有需要，可以提供修改导航属性同时修改关系的功能，用起来更加OO，可能有一些复杂的技术细节问题要解决。

目前通过导航属性获取(BO)对象，每次都从数据库装载，一定概率下会产生多余的查询。解决方法是在内存中统一缓存，通过ID判断若内存已有则不从数据库中取。这个方案一方面会增加一点内存开销，同时为了满足“就算内存中有，也要从数据库装载”的需求，需要设计复杂一点的机制。还需要解决前面的业务修改了的对象，后面的业务（同一个请求）获取是否应该获取修改后的这个对象版本的问题，我目前觉得应该获取修改后的版本，而不是数据库中那个。无论获取到的是哪个版本，会不会在业务处理上造成Bug，有待进一步研究。

系列导航

1-我的BO之强类型

2-我的BO之数据保护

3-我的BO之状态控制

4-我的BO之导航属性