浏览 3838 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-12-25
试图将用户需求合理的划分到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。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2006-12-26
建议去看看 color uml
|
| 返回顶楼 | |
|
发表时间：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。 楼上的在做什么产品呢？现实中有这样的用户 ？要是真有，也把它给踢回去。除非极为必要。 |
| 返回顶楼 | |
