我的BO
1-我的BO之强类型
2-我的BO之数据保护
3-我的BO之状态控制
4-我的BO之导航属性
弱类型的缺点
有些程序员对类型比较随意，从前端传来的数据，不管应该是什么类型，都以String接收。然后在什么地方转成应该有的类型则要“看心情”，在Controller, Service, DA都有，甚至有从头到尾都不转为正确类型的。这里把一切都用String表示称为“弱类型”，相应地该是什么就是什么类型称为“强类型”。比如Service方法的参数清一色String型的，其中的参数的位置传错了也发现不了。Long,Date型也是按String在各层之间传送，若在DA层没有一个强有力的组件保障，很容易就被黑客SQL注入。有些中途要作运算，不得已转为强类型运算，然后因为下一级是弱类型，又转为弱类型继续传递。许多地方明明可以判断两个值是否相等，却因为类型不同需要先作转化，转化的过程又因为值是null而出错，偏偏出错方面又没处理好，真是接连挖了几个坑等着人跳。
图：该是什么就是什么
正确的做法是用最正确的类型表示和传送每一个数据。至少在BO这一层，要完全强类型。
枚举类型
在DTO和数据库中，可能是String，可能是Integer，但对于BO来讲，它就只应该是枚举类型。这样无疑对业务处理是最方便的。
日期时间类型
前后端交互时，出于方便调试的目的，我们采用字符串来表示，具体格式是yyyy-MM-dd HH:mm:ss。 在DTO中体现为String型，而在BO中则为Date类型。
Java的Date出现得早，受广泛各种组件的支持，但运算不方便，LocalDateTime运算方便，但出现得晚，不受广泛支持。用Date还是LocalDateTime都算强类型。本来应该采纳运算方便的LocalDateTime，但考虑到需要运算的可能性小，不需要运算的可能性大，若采用LocalDateTime，就会增加不必的正反两次与Date转化。最终决定两种类型同时支持，内部关联同一个数值。在需要运算时，读写LocalDateTime型的属性时自动转化，在不需要运算时读写Date型的属性则不会产生两次额外的转换。两种类型之间的转换由BO内部自动完成，外部使用时哪种类型方便就用哪种，十分方便。
强类型的优点：
- 防止SQL注入
- 方便运算
- 正确的取值范围
之前我的一篇文章推荐使用的7种基本数据类型讲到这方面。在数据库提供的很多种类型支持的情况下，我们也只挑战少数几种类型使用。在BO层则是以最贴切的类型来使用，并不局限于7种。比如BO中使用的枚举型，在数据库中往往表现为String型或Integer型。两者并不矛盾。