MVC的Controller-Action布局:单独的创建/编辑页面还是创建/编辑/查看一体的页面?

刚开始的时候非常认同asp.net中MVC的Action的布局方法:无论大小,只要是一个动词,都给一个单独的页面,比如Create/Edit/Detail/Index。

编写了一段时间后,又发现这样很不方便,尤其是像“创建角色”这样的页面,就一个TextBox,其他什么都没了,单独编写一个Create一个Edit,不如在Index页面上方放一个TextBox,底下已经存在的角色也直接用TextBox而不是文本,这样想创建就创建,想编辑就编辑。

又编写了一段时间,又发现这样有风险。因为在另外一个页面上我把所有信息也这样做的,但这个页面会有大量的用户访问,很容易出现大家同时编辑同时更新的问题,锁都锁不住因为不知道谁在编辑什么。

到底怎么办呢?

虽然不能说找到了个完美方案,但终于说服自己这是个还算可以的答案。那就是:

对于多人访问的页面,Create/Edit/Detail/Index应该是分开的

我编写的是一个项目管理软件,因此需求、缺陷、组内的任务这些数据都会有多人查看,分开写有两个好处:

1. 避免了前面提到的编辑后更新冲突问题。

2. 很容易设置权限,比如有些人只能看不能编辑和创建,有些人可以创建,但是不能编辑别人的任务,等等。

3. 很容易用一个链接来作为外部接口。

比如可以把“xxx/Stories/Create”放到内部OA里边,访问的人就可以按一下创建一个用户故事(需求)。由于很可能是销售人员在创建,他们一是不应该有权限浏览所有故事,二是如果真让他们进入一个万能界面,反而不知道在哪创建故事好了。

对于单人访问的页面,这些视图可以且倾向于合并在一起

1. 典型的情况是Adm的所有功能,如果某一次要求把所有用户名都改成“last.first”,让他们点无数次Edit跑很多地方才能完成,不如在一个巨型编辑界面中集中完成。反正不会有无数Adm一起工作,即使他们请了帮手一起工作也肯定会事先协调,很安全。

2. “我的个人中心”,这个地方铁定是自己才会去的,里边很多信息都应该本着方便快速而非权限管理的原则设计。

3. 极少数团队领导才会操作的页面,比如计划/审批页面等。

 

这个思路是不是用提前预订的判定标准,而是遵循“在那种场景下,怎样做才是更好”得出来的,估计编到后面还可能发现新的规律,到时候再补充。


补充一点关于界面布局与产品理念的内容。 

本人后期的工作是管理软件的市场和销售工作,在工作中遇到了很多易用的不易用的产品,发现了一些潜在的规律。

在早期的软件开发中,习惯的做法是使用单一的功能强大的界面,来完成所有工作。比如Word和Excel,使用整整一天,都几乎在单一界面中完成;而无论使用者的角色如何,也都使用这个界面。因此当软件功能越来越复杂时,使用的难度也随之急剧上升。

从功能角度看,比如当你在Excel表中使用公式/条件格式这些功能时,一定觉得空间非常拥挤。那么大的屏幕,只有极少部分在为当前的操作服务。

从角色角度看,即使是Word/Excel这样的简单软件,也存在作者/评审者/阅读者这些角色,他们的权限、使用习惯、常见操作是完全不同的。单一界面就使得某些角色感觉到很不舒服。

在近期的软件开发中,由于Web的出现,单一界面已经逐渐倾向于完成单一功能。各种网站是个典型,比如新浪,其核心功能和代码量可能并不会超过Office,但是其界面数量却巨大的得多,而带来的效果是:任何人在新浪上面是不会迷路的,也不会觉得功能繁杂无所适从。

从功能角度看,分拆界面的好处是:

1. 几乎不用额外地开发对外的API了。

若一个界面提供且只提供一个功能,则这个界面的链接就是那个功能的API;

2. 权限控制变得简单多了。

如果一个界面中包含众多功能,登录的人到底能操作和不能操作哪个功能就是一个很复杂的工作,要在View中做大量工作,而现在所有工作都在Controller里边完成。

从角色角度看,分拆界面的好处是:

1. 角色各自查看自己的内容。

千万不要认为给他更多内容一定会更好,其实不然。上次在培训课上,练习的时候就有人写了一个用户故事,这个故事是“作为一个用户,可以登录系统查看项目及自己的任务,以便……”,当时的内容是“用户建模”,就是要弄清楚谁会用这个功能,而分析结果是:“高层,中层,产品经理,项目经理,组员都会用到这个故事。”这个就麻烦了,因为这些人的工作内容截然不同的,上来看内容的重点也就不同。这个界面即使设计出来,也一定有人觉得不方便。

2. 角色各自操作自己的功能。

如果界面上明明有一些TextBox,用户也高高兴兴地填上一些内容,按下按钮时才出来:“您没有编辑权限”,是一件非常令人恼火的事情。分拆界面后,各自去各自的界面,没有编辑权限的人就看不到TextBox。

分拆界面的坏处则是批量操作的能力变差了,因此若此功能非常重要,可以尝试在大量批量操作的界面上做复合型界面,配合jquery的focus功能等,做出一个以最小操作数量完成操作的界面。

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

posted @ 2011-08-09 15:35  Java EE  阅读(235)  评论(0编辑  收藏  举报