如何辨别用户需求应该属于M/V/C的哪个部分？

试图将用户需求合理的划分到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。

评论

2 楼 together 2006-12-26  

clamp 写道

试图将用户需求合理的划分到M/V/C各个层次上，往往不是那么轻松的事情。

一个很简单的例子：人员管理。对象包括部门、人员。一个部门下可以有多个人员。
在普通的增删改查操作下界限是清晰的。

需求1
   要求在部门列表、部门编辑时展现部门内的人员总数。

这个值加在哪里？
M:将这个统计数视为部门对象的一部分。这种设计思路一直是很有争议性的
C:临时性获得这个值，似乎是比较正统的做法。
V:需要显示这个值，基础框架搭的好的V很可能不用变动代码。
如果采用hb，则直接在V层显示就可以了

需求2
   要求在部门列表、部门编辑时针对不同的人员总数的值显示不同的颜色，0-10个人的部门用黑色，11-50的部门用黄色，51以上的部门用红色。

这个逻辑放在哪里？
M:比较少见
C:做业务逻辑似乎比较合理，但是要将颜色和边界值传递到V，很可能会受到限制。
V:可能是更常见的做法
理所当然要放在M层
以下有兴趣的人自行思考吧

需求3
   需求2中的边界值可以临时改变，不需要保存改变后的值，只对某一设立了改变值的用户有效
这样的需求，属于业务逻辑吧，M层
？？？

需求4
   需求2中的颜色可以临时改变，但不需要改变保存后的值
这样的需求，也属于业务逻辑吧，M层
？？？

需求5
   需求3中的边界值改变以后需要保存，且对所有用户有效，不要求即时刷新

？？？

需求6
   需求4中的颜色改变以后需要保存，但是针对不同用户可以保存不同的颜色

？？？

需求7、8……

btw:以前项目中遇到过类似的例子，用户提出了需求1和2，最后的结果是只做了需求1。

楼上的在做什么产品呢？现实中有这样的用户 ？要是真有，也把它给踢回去。除非极为必要。

1 楼 tuti 2006-12-26  

建议去看看 color uml