層？為什麼軟體開發要分層

層？為什麼軟體開發要分層

一、事由
        最近一直在做項目的前期調研，大致的設計方案已經出來了，在與合作公司的另一個工程師做交流的時候，他突然冒了一句：本來簡單的項目你們為什麼還要用架構，還要分層開發！

        那個工程師以前做了很多年軟體，VB、ASP的年代吧，現在主要轉向做總工工作了，負責專案管理協調，我們公司是承接其中一部分軟體項目，前些時候向他講了一下我們開發的方式，主要是多層開發，團隊合作的情況，基本沒有講通。這次拿了調研的結果他卻說要是用ASP之類幾天就做完了（實際項目規模編程需要6個人月時間），根本就不需要那麼麻煩。一方面作為合作方他要貶低我們的工作方便商務談判，另一方面確實有這方面的疑問，我想好好的分析一下他們的問題，談談自己的想法。 整理了他的問題：
         1.為什麼要分層？
         2.如果分層是為了分工，那每個人分一個模組不是也很好分工嗎？
         3.分層如何提高工程效率，小項目是否還用分層？

二、經曆
以下僅是我的個人意見，參考而已，我先介紹一下自己的經曆：
        我最開始做的是單片機的開發，後來是WinCE的開發，基本都是一個人在做，和別人溝通的很少。程式就是一段一段的寫，對資料庫的操作很少，只有在WinCE上有一些SQLCE資料庫的開發。
        後來參與Team 專案的軟體開發，Delphi程式，幾個人一起，每個人分一個功能模組，項目負責人告訴我如何畫介面、寫程式、串連資料庫、使用控制項等等，掌握這些用了很長時間，很多經驗除了別人傳授更多的還需要自己去體會。
        再後來給一個項目作實施，那個項目是Java開發的，用的就是多層的開發方式，不僅將資料層封裝了，同時對頁面也進行了封裝，那個時候比較可笑的是，僅作了半天的培訓就開始進行軟體實施，對程式的瞭解還沒有客戶知道的多就四處跑的給人家裝程式，不過收穫也蠻大，一個是熟悉了如何與客戶進行溝通，還有就是對多層開發產生了濃厚的感興趣。
       之後的一段時間裡我開始自己寫.Net的資料訪問層架構，從網路上整理資料，現在這個架構已經應用了幾個項目，應該是成功的，比自己預期的要好很多，也基本滿足了網路上朋友們對資料訪問層的要求。
        這個架構名稱是：FrameCountry資料訪問層架構，是在.Net平台下主要針對多層架構中資料訪問層功能的，可以做到：
          1.不同資料庫相同的開發、配置方式，儘可能的降低資料庫操作差異；
          2.開發快速，對資料層的函數進行多樣封裝，開發人員主要精力放置在業務實現上，對資料庫的資料操作變得很便捷；
          3.對程式的過程有詳細的記錄，記錄操作資料的正確、異常、錯誤、事務資訊；
有興趣的朋友可以到下載最新的FrameCountry架構：
http://blog.csdn.net/lizheng82/archive/2007/06/18/1656140.aspx

       從我的經曆來看，走了如下的四步：
       1.獨自編程，簡單軟體
               項目規模很小，整個軟體系統由自己完成，很少與合作者進行溝通；
       2.合作開發，非多層方式分工
               軟體開發由多個人完成，每個人分配不同的功能模組進行開發；
       3.項目實施，接觸多層方式
               開始瞭解多層軟體開發的結構；
       4.應用多層開發
               完成資料訪問層架構，並進行項目開發；
       基本上包含了幾種開發的方式，也有些自己的體會。

三、架構理解
       言歸正傳，我的情況基本介紹了，現在開始說正題。我理解的多層架構是以四層為標準，分層如下：
       1.展示層
               實現使用者操作介面，展示使用者需要的資料；
       2.業務層
               完成商務程序，處理展示層提交的資料請求，使用資料訪問層操作資料；
       3.資料訪問層
               接收業務層的資料庫操作申請，完成資料庫操作，記錄日誌資訊；
       4.資料庫
               儲存資料的關係型資料庫；
       可能這樣說比較抽象，我們可以舉個例子，假設需要對資料庫表Table進行修改操作，修改完資料後將修改人、修改時間、修改數值儲存到資料庫庫中，看：

       現在再次以為例再說明各層應用描述：
       1.展示層（使用者頁面）
               在頁面初始化時載入初始化資料，顯示修改的編號、名稱數值，使用者修改數值後點擊“修改”按鈕，向業務層提交修改請求，並將修改的數值傳遞到業務層；
       2.業務層（實現商務程序）
               將使用者介面傳遞需要修改的數值整理後向資料訪問層提交修改申請，然後將修改時間，修改人的資訊再次提交給資料訪問層進行插入修改記錄的操作；
       3.資料訪問層
               業務層提出的操作資料庫請求，組合成資料庫識別的SQL語句，向資料庫提交操作，並將結果反饋到業務層；
       4.資料庫
               儲存資料的關係型資料庫；

四、問題
       說了那麼多的話，現在開始回答那些疑問，三個問題就一起回答了。
        首先軟體分層開發是否有必要！回答的是肯定的，就像問現在電腦辦公是否有必要一樣，趨勢，別人都這麼做了，也做得很好，那當然就有必要了。我認為多層開發的好處：
        1.方便團隊分工
        以前的按功能模組一般是幾個人將項目的功能模組一分，每個人從操作資料庫、完成商務邏輯到實現介面都要獨自完成，當然資料庫的設計可以由一個人完成，這樣的開發顯然有弊病，首先每個開發人都需要掌握大部分技術，還要有很強的商務邏輯的理解能力，其次每個人的開發習慣都不同，形成的代碼繁雜可讀性差，最後後期的完善、維護都會造成麻煩。相信很多人都會理解這樣的痛苦經曆，多層開發就能解決上面的問題嗎？如果是一個合理的多層開發模式是完全可以解決的。
        將軟體開發分層，其實可以簡單的理解為工種分層、規範代碼，基本可以將工作分為介面設計人員、業務實現人員、資料庫設計人員。介面設計人員的工作就是畫程式介面然後將資訊提交給業務層，不需要考慮業務層的邏輯關係，業務實現人員的工作是處理介面提交的資料請求完成邏輯流程，再結合資料訪問層，不用考慮介面設計的樣式、風格，也不用考慮資料庫的格式，資料訪問層一般是設計完善的架構系統，基本不需要人員工作，主要是屏蔽掉資料庫間的差異，為業務層提供便捷的操作功能，資料庫設計人員就是設計、規劃資料庫。很顯然一個團隊採用多層開發就可以合理的分配人員工作，將每個人放置到適合的崗位上，而主要的技術人員集中在關鍵部位的開發工作，重複簡單的勞動，如畫介面就可以安排給新手來完成。
        2.其他特點
                 還有以下的一些特點：
        規範代碼：在開發過程中可以將每層的代碼進行規範，固定開發語言的風格；
        忽略資料庫差異：好的資料訪問層可以將資料庫的差異完全屏蔽，對開發人員只是做相同的資料操作工作，甚至可以快速進行資料庫轉換；
        基本上就想到這些，還有的就等日後慢慢整理了。
        現在回到那個問題，分層是否有必要，其實回答否定也可以，並且有理者也可以說出一大套理由來，所以還是看實際需要，再有上述為筆者的淺見，僅作參考。