基於MVC團隊組合模式的系統開發

標籤：style   c   java   tar   ext   http   

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

更多詳情