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團隊組合模式我基本上說的差不多了。我曾經在一些項目中使用過它，有說好的當然也有暴跳罵娘的，終究是孰是孰非，誰對誰錯，我也不得知曉，只待各位自己去想，去悟。