2B面向对象的业务的一些总结经验（持续更新）

1. 面向对象表结构设计之关联

场景

主对象：设备

属性：设备类型 设备等级

两者异同

同：都是设备的关联属性

异：类型是散列的 等级是线性的

结论

设备类型的配置表完全可以通过id关联，符合传统表结构范式规则；

设备等级的场景极有可能出现逻辑运算（如将中等及以上的设备做一个查询之类的）此时需要通过具体的等级内容做关联即1、2、3等，需要注意关联等级配置表对level的唯一性做好维护；

 

2. 2B项目枚举字段的类型抉择

1.枚举型字段的三种情形

1.1.是否 0是 1否

1.2.状态 0正常 1~∞ 非正常

1.3.类型 list

枚举型基本上述三种情况

 

2.枚举型配置的两种情况

2.1通用字典 为了通用性一般设置成string类型

2.2专门的类型配置表  如 设备类型

 

3.数据库字段类型的抉择思路

3.1如果要通过字典来管理 上述三种情况都要用字符型

3.2如果要通过专门的类型配置，根据类型的数据类型而定（类型如果是可编辑的必须用主键关联）

3.3如果是自由的，建议数字型对搜索效率友好，但是每次都要和前端约定，后端还要枚举类翻译，不好管理， 一般1.1 ，1.2会遇到

 

3. 逻辑删、物理删、状态字段理解

逻辑删请直接理解为物理删除，他的意义在于运维日志的查看，而不是在业务逻辑中去操作逻辑删字段；

所以在开发人员的角度来看逻辑删=物理删；

一旦出现类似文件的“删除”“回收站恢复”千万不能用物理删除、逻辑删除的概念去做；而是增加状态字段来做业务逻辑的需求；否则就会出现物理删除引起的数据一致性问题，进而导致在业务逻辑中去操作逻辑删字段，使得各种关联逻辑产生很多额外的非空判断，使得业务逻辑又臭又长；

 

 

4. 关于表单更新包含其他对象的联动更新时的处理策略

当表单的更新对象需要联动更新到其他对象表时，如果联动的代价非常大，需要对这部分修改属性做“有无改动”的判断，会产品非常多的判断逻辑，导致代码冗余维护难度提高；

此类场景建议将修改的部分参数单独提出，责任单一；

举个例子如下，文件夹的可见范围属性需要批量更新到递归下的所有文件，如果文件数量巨大，非常容易造成死锁等待。而大部分情况下这些属性是不会改动的，然而前端是会一股脑

提交即是没有变动，所以就要后端自己去判断数据是否有修改，如果有修改再批量更新。

而如果将此部分属性提出，则责任单一，修改可见范围的动作必然批量更新，而原本的自身属性修改可以完全不用去管“有无改动”的判断。