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功能等，做出一个以最小操作数量完成操作的界面。

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