试图将用户需求合理的划分到M/V/C各个层次上,往往不是那么轻松的事情。
一个很简单的例子:人员管理。对象包括部门、人员。一个部门下可以有多个人员。
在普通的增删改查操作下界限是清晰的。
需求1
要求在部门列表、部门编辑时展现部门内的人员总数。
这个值加在哪里?
M:将这个统计数视为部门对象的一部分。这种设计思路一直是很有争议性的
C:临时性获得这个值,似乎是比较正统的做法。
V:需要显示这个值,基础框架搭的好的V很可能不用变动代码。
需求2
要求在部门列表、部门编辑时针对不同的人员总数的值显示不同的颜色,0-10个人的部门用黑色,11-50的部门用黄色,51以上的部门用红色。
这个逻辑放在哪里?
M:比较少见
C:做业务逻辑似乎比较合理,但是要将颜色和边界值传递到V,很可能会受到限制。
V:可能是更常见的做法
以下有兴趣的人自行思考吧
需求3
需求2中的边界值可以临时改变,不需要保存改变后的值,只对某一设立了改变值的用户有效
???
需求4
需求2中的颜色可以临时改变,但不需要改变保存后的值
???
需求5
需求3中的边界值改变以后需要保存,且对所有用户有效,不要求即时刷新
???
需求6
需求4中的颜色改变以后需要保存,但是针对不同用户可以保存不同的颜色
???
需求7、8……
btw:以前项目中遇到过类似的例子,用户提出了需求1和2,最后的结果是只做了需求1。
一个很简单的例子:人员管理。对象包括部门、人员。一个部门下可以有多个人员。
在普通的增删改查操作下界限是清晰的。
需求1
要求在部门列表、部门编辑时展现部门内的人员总数。
这个值加在哪里?
M:将这个统计数视为部门对象的一部分。这种设计思路一直是很有争议性的
C:临时性获得这个值,似乎是比较正统的做法。
V:需要显示这个值,基础框架搭的好的V很可能不用变动代码。
需求2
要求在部门列表、部门编辑时针对不同的人员总数的值显示不同的颜色,0-10个人的部门用黑色,11-50的部门用黄色,51以上的部门用红色。
这个逻辑放在哪里?
M:比较少见
C:做业务逻辑似乎比较合理,但是要将颜色和边界值传递到V,很可能会受到限制。
V:可能是更常见的做法
以下有兴趣的人自行思考吧
需求3
需求2中的边界值可以临时改变,不需要保存改变后的值,只对某一设立了改变值的用户有效
???
需求4
需求2中的颜色可以临时改变,但不需要改变保存后的值
???
需求5
需求3中的边界值改变以后需要保存,且对所有用户有效,不要求即时刷新
???
需求6
需求4中的颜色改变以后需要保存,但是针对不同用户可以保存不同的颜色
???
需求7、8……
btw:以前项目中遇到过类似的例子,用户提出了需求1和2,最后的结果是只做了需求1。