MVC团队组合模式，主要源于J2EE中常说的MVC演变而来。确切地说这个东西是我自己杜撰出来的，但又经历过一些项目实践，今天拿出来在与大伙这里说说，一来弥补一下自己长期不写技术类文章的缺陷，不然很多人又说我作为一个软件人，在博客中连起码的技术东西都没有，很是惭愧。二来也想把自己经历过的丁点经验告诉大伙，至于是对是错，有用与否，那只有天晓得了，哈哈。。。。

　　 说到MVC团队组合模式，那就要说说我的框架WMframework，

　　 WMframework现阶段采用主要技术有：s2,ibtatis2,spring3，HTML，js， xml，ajax，整个技术框架也是自己杜撰出来的，一直自己在默默地喜欢着，改进着，这些年的程序员生涯也就剩余这点东西可以怀念下了。我向来不是吝啬的人，所以在后面的时间里我会逐步把自己的WMframework拿出来与大伙分享，希望有心的你可以期待，当然更梦想得到大伙的真知灼见。今天我主要说的东西还是我的团队中如何使用MVC团队组合模式进行软件开发。

　　 MVC团队组合模式？

　　何谓“MVC团队组合模式”，主要意思就是把一个团队里面的各成员按其个人综合技能进行分工协作，具体地说就是针对每个业务模块的开发，采用各成员进行分工协作完成的模式。一个模块，张三完成一部分，李四完成另一部分，王五又完成其他部分。这有别于大伙常见的由一个人承担某个模块的开发合作模式。

　　 先来说说我们常见的开发模式。大伙都知道，我们通常的软件系统开发中，很多时候都是这样的，先由项目经理或小组长做统一的任务分配，把具体的各功能点模块按人头分配给团队中的各程序员们。比如用户注册张三负责；组织机构管理李四负责；哪天哪天这个模块由谁完成，哪天哪天这部分由谁实现。整个编码计划就是这样指定下来，直到系统的所有功能模块都被分摊到相应的开发人员身上。等待我们的程序员把各模块都编码完成，大伙再把这些代码、功能进行系统的整合、集成、测试等，这就是大家常见的甘特图模式，也是我们通常碰见的开发模式。

　　 我提出的MVC团队组合模式，区别于上面最大的不同就是，我把任何一个业务模块开发任务分为3部分，由三类不同角色的人员来共同完成，这三类人员我称它们为MVC，即M_actor 模型执行者、V_actor 视图执行者、C_actor 控制器执行者。

　　 下面我给出这三者的主要描述：

　　 M: M_actor 模型执行者

　　 主要任务：后台业务处理模型，主要就是Dao，sqlmap的编写；（在WMframework中，我已经弱化了dao这层，因为在WMframework中我们的dao都是公共的，开发人员基本上不用写dao。）

　　 个人要求：要求开发人员对数据库操作能力强，对整体业务流程充分了解，保证其sqlmap编写的sql完成当前模块的业务需求。

　　这部分可以由擅长数据库开发人员和需求分析人员结合完成。

　　V：V_actor 视图执行者

　　主要任务：前台表单视图，主要就是jsp，html，js的编写；完成页面数据表单的设计、实现、业务数据的js校验、提交等。（在WMframework中，我对于页面表单数据提交、校验也是一个公用的自定义js前台框架，开发人员只需要写简短的几句js脚本调用即可。）

　　 个人要求：开发人员需要有很好的UI设计能力，可以更为人性化地实现页面操作，使其有更好的用户体验，知道些js语法和html标签使用即可。

　　 这部分由美工、UI技术人员和需求分析人员结合完成。

　　 C：C_actor 控制器执行者

　　主要任务：s1/s2中的action，业务层接口service的编写；

　　个人要求：开发人员熟悉常用的java开发模式，有很好的java开发能力，能很好地处理request请求，respronse返回响应等。（在WMframework中，我同样弱化了action的使用，很多时候对于多数页面请求只需要调用公用的action即可，开发人员基本上不用自己写）。

  　 这部分资深java开发人员完成。

　　 MVC团队组合模式优势

　　 通过我的介绍看出些好处没有？很明显，若采用MVC的开发模式来在组织团队人员，对不同类型的人员要求就不尽相同。

　　 C_actor 可以完成不用了解系统业务，他们只需要关心如何解析前台提交的请求数据，就WMframework而言就是完成从request里面读取xml转化为bean(这里说的bean也就是我们常说的pojo、vo、bo等)的实现；然后通过外部接口service转交给内部实现dao，最后在dao中完成持久层的相关操作；

　　 V_actor 可以完全不用了解什么叫j2EE，只需知道jsp的表头怎么写（其实很多时候不用写，因为我们都是include进来的嘛），合理地设计页面表单的布局，知道哪里该放button，哪里该用text，哪里摆个textarea，哪里该弄个select等，仅此而已；

　　 M_actor不需要关心用户界面如何设计，该怎么制作，用户数据以什么方式提交。他只需要清楚当前业务涉及那些数据模型，各数据表中相应的字段是否填上，哪些是必填项，数据类型是什么，数据大小如何定义，数据存储是否正确等。

　　 如果联系到公司人员配置问题，这里也有一点优势在里面。因为很多时候，很多公司，总会在项目来临一味扩招，项目结束一味削减，而最终能保留下来的也就是那么几个核心人物，当然我这里不是提倡这样的作法，毕竟多少有些凶残。如果你的公司，你的项目采用了我说的MVC团队组合模式开发，那很多时候，你的核心开发人员、业务人员依旧全力地支撑着整个项目，他们掌握着整个项目的核心，所以很多时候，你可以重点培养M_actor与C_actor，对于V_actor自然多少有些微不足道，弃之无妨。不过做人起码需要些厚道，尽管商场残酷，商人无情，终究我们都是人，应该多一点感情，多一点良知。实在不想要他们了，能最大限度给点补偿也不枉人家为你卖命一场。

　　 以上这些就是我能看到的基于MVC团队组合模式开发的优势，使用它可以让我们的开发人员减少许多需要关注和学习的东西，有时候闷头想来做一个合格的java web开发者，你最基本的可能需要知道这些：java、jsp、js、xml、css、sql、ide、html等，太杂，太多，太烦。但如果你使用如上所说的开发模式，让开发者专注于各自所特长的一方面，并进行很好地发挥，最后更好地完成自己的任务，做好自己喜欢的工作，那种感觉应该会好很多。起码是辛苦并快乐着，哈哈。。

　　 MVC团队组合模式劣势

　　 前面竟说了些好听的，下面我来说说MVC团队组合模式的弊端，最明显的一点就是，各类型成员间开发任务的同步性、顺序性、可用性测试、问题跟踪等。比如一个用户基本信息维护模块，如果某天客户需要增加一个用户生日的信息，必然会涉及 C_actor进行业务数据对象修改,M_actor修改sqlmap中的insert,select,update等语句，V_actor 修改表单jsp增加生日的输入框等。又或者用户基本信息业务模块出现异常（数据不正确，不能保存等）也必然需要C_actor、M_actor、V_actor来配合完成跟踪，这自然也就增加了当前任务消耗的资源。再或者用户基本信息业务模块不能在规定的项目计划时间完成，其最终的责任应该算在谁的头上。C_actor说用户表单没有设计，如何完成action的编写，V_actor抱怨数据模型没有给出如何知道页面元素类型，哪些应该必填，哪些应该选填，哪些应该下拉，哪些应该只读，我都不知道，叫我如何设计页面；M_actor呢，咆哮V_actor页面表单都没有，叫我如何知道业务模型需要那些字段，需要什么样的数据类型，需要多大长度。最终是个个推诿，人人有理，整天就是这样缠绕在彼此间借口的闭环中，周而复始、无穷无尽。哎，程序员，难啊。。。。。

　　 凡事皆有两面性，对于MVC团队组合模式我基本上说的差不多了。我曾经在一些项目中使用过它，有说好的当然也有暴跳骂娘的，终究是孰是孰非，谁对谁错，我也不得知晓，只待各位自己去想，去悟。