敏捷开发用户故事系列之七：用户故事与MVC.docx

敏捷开发用户故事系列之七：用户故事与MVC作者:cheny_com发布时间: 2011-10-12 23:45用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易把故事写坏。但是MVC和用户故事有很大的关系，如果用户故事写好了，做MVC的时候，一定要记得参考用户故事。本人在C+的年代用过MVC，但那个时候MVC还只是一种编程思想，说用了也行，说没用也行。但到了C#之后，就出现了正牌的自称是MVC的东西（现在最新版本是MVC3），本人也在用。Java世界也有MVC的概念，但是没有见识过，下文中所描述的MVC，若没有特殊说明，均指A MVC；但相信对Java中的MVC也有借鉴意义。利用MVC实现用户故事的技法如果您已经认可之六中产生用户故事的方法，那么也就得到了这样的一个用户故事树，右边则是为其量身定做的Controller-Action（来自实际项目）：下面是对应的Controller-ActionsUsersController-Users/Index-什么也不是-/Users/Details-/Users/User2Authorities-/Users/Users2Roles-/Users/Freeze-/Users/Edit-/Users/Delete-/Users/BatchCreateRolesController-Roles/Edit-Roles/Details-Roles/Delete-Roles/IndexAuthoritesController-Authorities/URA-Authorities/Delete-什么也不是-Authorities/Index-什么也不是-/Authorities/Authorities2Roles-/Authorities/URGA注意看每个Controller实现了一个史诗故事（要管理的数据），每个Action则实现了一个（偶然多个）用户故事（用户的业务操作），有几个值得注意的地方：1. 一个Controller几乎正好可以实现一个史诗故事2. 一个Action因为正好是一个动词，所以几乎正好和一个用户故事对应。有两个地方违反了，如“角色首页（新建+查看）”和“权限首页（新建+查看）”，因为为了方便我们在两个Index里边放了个新建用的TextBox，方便直接创建（因为角色和权限都只有一个名字而已，所以觉得犯不上做个独立页面了）。为了能记住这一点，我们在故事的缩写名字上加了（XX+XX）的标记，为了日后能自动计数故事。3. 用户没有“创建”故事，也没有Users/Create，因为用户只有两种正常的创建方法：Register和BatchCreate，我们选择了后者。因此既没有“创建用户”这个故事，也没有“/Users/Create”这个Action。4. 几个绿色箭头是“增强”类型的故事（详见之五），它们正好也不对应Action。上面提到的是我们实际的一种用法，未必是普适的，但在我们项目中非常适合，甚至应该称为“舒服极了”。这种史诗-故事与Controller-Action之间偶然的巧合，实际上背后有其必然性。利用MVC实现用户故事的心法MVC以往研究的重点，是何为M，何为V，何为C，以及三者之间的关系。我们在用了一段时间后，发现其中的每一个，都还有更深层次的理念在里边，这里谈的就是Controller及其Action。在MVC三者呆在一起的时候，问：何为Controller？估计还是挺容易回答的。但如果不提MV，直接问：何为一个Controller？何为一个Action？却挺难回答的。如果去一个非MVC的网站或软件，最令人烦恼的，是网站的每个页面未必有自己独立的链接，比如逛了半天，顶上的链接一直是http:/xxx./login=xxxx，想为某个页面加个收藏夹都不行。MVC在很大程度上解决了这个问题：要操作的数据是Controller，要做的操作是Action，而参数则是具体操作谁，比如/Users/Details?user=cheny或CSDN博客上常见的：/cheny_com/article/details/6616794样式。所以如果已经按照之六中提到的数据-操作方法来组织史诗-故事结构了，而且又在使用MVC,则非常推荐编程时将其继续映射到Controller-Action中。可能细心的读者已经注意到本文图中有些故事后面有个链接符号，那个正是我们在已经实现了的即金色的故事的后面，加上了其超链接（全部是/Controller/Action，一一对应，非常舒服）。这相当于一个Action写好了，一个故事（偶然情况是多个）就正好也完了；而测试人员就可以点击那个链接去到Action测试。他测试完了Action，就能说故事被测试完了（而不只是Action被测试完了）。以这种方式来对应用户故事和开发内容，产品经理和开发人员很容易沟通，因此非常推荐使用。用户故事 vs. FPA功能点分析法 vs. MVC功能点分析法（FPA）、敏捷开发用户故事、A MVC在一定程度上具有相同的目的：作为用户需求与开发人员工作的桥梁，只是侧重点有所不同。因此若能将它们联合应用，就可能用一种组织方