1.面向对象
对象可以和数据底层模型 一一对应
但是，当使用到相关业务的时候，我们往往会往模型里塞多种属性
会导致这个模型变得臃肿庞大
别人再使用的时候，也同样往模型里添加各种业务属性
业务模型成了各个业务的垃圾桶
变得越来越无法维护了。
建议：业务模型的属性是固定的。各个业务使用的时候，可以使用继承或组合来扩展。
2.参数模型
参数的获取可以设计为接口的形式。
通过接口的形式获取参数，而不提供具体的实现。
实现交由业务调用方，自行创建和维护。
3.业务模型
业务模型不应该是和数据库底层的表模型一一对应实现，而应该对应于具体的业务逻辑。
有时候，一个业务逻辑可以对应于多个底层的模型。如实现一个角色的维护业务，可能对应用户，角色，和用户角色表。
也有时候，多个业务逻辑，可能对应于一个底层模型。如登录认证的业务，和用户的增删改查业务。
4.数据交互层模型
数据交互层，只是实现了业务表相关的操作，而不应实现复杂的业务逻辑。
建议只实现简单的增删该查操作，而不应具有具体的业务含义，只有如此才能保证数据层的独立性。
数据交互层只负责从数据库中读取，修改，插入和删除。