实际案例
最近接手一个任务系统,后台配置满满一篇的任务相关属性,包括了名称、类型等固定字段和各种各样可选的达成条件。数据模型的设计也就和试图模型一样,有很多字段,估计是长期不断加需求慢慢演变成这样的结果。
现在面临的问题是做任何改动逻辑都很复杂,所有的逻辑都是在分析同一个模型的各种字段。
糟糕的设计
需求是怎么样就数据模型和视图模型就都设计成什么样,不断的增加数据字段。
弹性设计
重要原则是:尽量保证数据模型的精简和视图模型的完整。也就是说,数据模型和视图模型是可以完全不同的,仔细分析需求,将固定属性项放到数据模型中,类似的可选项抽象成另一个数据模型。
实际案例改造
本例中,可以将达成任务的条件抽象出来,另外建一个数据模型,数据库存取和逻辑处理都用这个模型,要给视图时再转为视图模型。
网友评论