涉及到的设计原则

• 单一职责原则

• 过度设计原则

推荐方式

如果在项目设计时，能够预料到以下几种应用场景的，建议分离为不同的业务对象，分离后可使用AutoMapper组件在业务对象与实体对象之间进行属性赋值。

• 业务对象需要进行缓存的

• 业务对象复杂，需要由不同的实体对象来分开进行存储的

案例

有一实体对象PmsPara系统参数，刚开始时不需要缓存，也是单表，所以业务层直接使用了实体对象做为业务对象。
后来随着系统参数的增多，发现对系统参数表的查询语句非常多，而系统参数的更改频率其实并不高，所以考虑增加缓存来减少数据库压力。就直接将整表的数据缓存到redis中，确实减少了数据库压力。
后来发现，有时从redis中加载缓存数据时间会比较长，达到20ms左右，由于redis的单线程特性，会导致其他请求被阻塞而出现超时，发现是缓存的数据随着系统参数的增加，量越来越大引起的。而之前是整表缓存的，其实很多字段都是不需要缓存的，比如修改人，修改时间等等。所以就打算业务接口，让其只返回必要的几列即可。而此时由于好多业务接口中都使用到了此业务类，本次重构的修改量还是比较大的。
重构完成后，就在想，如果一开始能想到数据需要进行缓存，而把业务类和实体类分开，即使想调整类属性也不需要大面积的进行重构了。