為什么要使用框架呢？Web開發框架怎么選？

為什么要使用框架呢？

使用框架的必然性

框架，即framework，說白了，其實就是一些應用的半成品。通常情況下，為了方便應用，會把不同應用程序中一些共性的東西剝離出來，做成一個半成品程序，這樣的半成品就是程序框架。當然，這些東西有免費的，也有付費的，免費的在功能上和后期維護上需要更多的心思，而付費的通常由一些開發企業做優化，開發一些標準功能，再加上一定的拓展，維護成本上會更低一些。

目前，軟件系統的發展已經相當復雜了，特別是服務器端軟件，涉及到的知識，內容，問題太多。在某些方面使用別人成熟的框架，就相當于讓別人幫你完成一些基礎工作，而你只需要集中精力完成系統的業務邏輯設計。這樣每次開發就不用白手起家，而是可以在這個基礎上快速搭建。

這樣一方面可以減少重復開發工作量、縮短開發時間、降低開發成本，另一方面也可以使程序設計更合理、運行更穩定，減少了人員流動所帶來的困擾。基于這些原因，基本上現在在開發中，都會選用某些合適的開發框架，來幫助建立快速高效的開發應用系統。

那么有了這些必然性，選擇就很重要了，在web層的開發框架中，有一些基礎思想很值得注意。

1.數據展示

Web層需要從邏輯層獲取需要展示的數據，然后以合理的方式在頁面進行展示，要做到分類明確，抓取精準，使用方便，界面簡潔。

2.人機交互

人機交互，其實是說的軟件智能化。比如用戶要在界面上輸入數據，并在界面上進行點擊操作，那么就可以觸發事件，建立標準的事件驅動模型，然后自動與后臺機型數據交換處理，從而完成新界面的建立。

3.收集數據，調用邏輯層接口

這個過程的觸發和用戶的操作請求是同步的。通常web層收到用戶的請求，便需要相應的邏輯層接口來處理，因為本身web層是不會進行任何邏輯處理的，這其實也是前后端的差異。而調用邏輯層接口，需要傳遞參數，這時需要收集用戶在界面上輸入的數據，然后進行組織，組織成為邏輯層接口需要的數據封裝形式，這種形式有很多，常用的是ValueObject。

4.根據邏輯層的數據來重新展示頁面

邏輯層處理完了，但是前端顯示依然沒有變化，這時候需要將數據或信息重新返回到展示界面上，界面再將數值分配到具體的位置，新的頁面便展示出來了。

其實通過以上我們也可以看出來，web層的開發工作重要集中在展示上，也就是圖形用戶界面，這是用戶最直觀的感受應用程序的窗口，通常也是用戶要求比較多的地方之一，其表現形式相對豐富。

Web層開發步驟

其實，任何項目從零開始，開發步驟都大同小異，只是有條件的企業會采用同步開發的模式，以節省時間，這里以基礎模式為例，簡述一下。

1. 確定展現內容，寫頁面Html

2. 每個數據的具體表現形式，如：有的需要表現成為下拉列表，有的需要表現成為單選按鈕等。

3.界面表現形式的邏輯布局，所謂邏輯布局是指某些數據的表現形式應該放在前面，某些應該放在后面；某些放在上面，某些放在下面。如：某個請假申請 的業務，有請假開始時間和結束時間，很明顯開始時間的表現就應該排在結束時間的前面。而美工是負責最后頁面的美觀，一般美工不能動界面的邏輯布局。

4.完成前面3步，頁面的表現形式的大致模樣就有了，下面需要來做功能性的開發。第一個就是這些表現形式的值的來源，如：下拉列表顯示的值從什么地方來。值的來源方式很多，有數據庫中來、固定值、某斷程序運行的中間結果、前面頁面傳遞過來等等，當然典型的還是來自數據庫。

好了，確定了值的來源，開發人員就要寫代碼來獲取這些值，然后把這些值賦值到對應的表現形式里面。

5.還有一些比較特殊，也就是真實操作的是一類值，但是在界面上顯示的是另一類值，比如：數據庫中有用戶編號，到了界面上就得顯示用戶姓名，但是所 有的操作都是要操作用戶編號的。我們把這種情況分做：真實值和表現值，他們有一定的內在聯系。這些都是要開發人員去轉化和維護的。

6.接下來就應該開發功能性的事件響應了。用戶點擊了某個按鈕或者觸發了某個事件，首先是客戶端：數據檢測、客戶端事件處理;然后提交到服務端，服務端要獲取到客戶端提交的數據，然后調用相應的邏輯層接口來響應。當然如何寫邏輯層的實現這里就不去談論了。

7.邏輯層執行完過后，返回數據和信息到Web層，開發人員還需要寫代碼去處理，選擇哪個頁面來顯示，如何顯示這些數據和信息等。

8.在整個交互的過程中，還必須考慮到如何控制權限，如：某些數據不能顯示，某些數據不能編輯等等;同樣還需要考慮到消息的配置和國際化等等。這些功能起源于邏輯層，但是實際的控制要到Web層，這些都需要開發人員來控制。

9.完成了上面的開發步驟，頁面基本的功能開發就告一段落，接下來開發人員需要考慮頁面美觀的問題了。大家可能會說：“不是有美工嗎，還需要開發人 員干什么?”。事實上美工多半只能出一個靜態頁面的美化模版，美工對于一推Java代碼和Html的混雜物，多半是沒有辦法的，更不要說還有一些內容是動態生成的，美工就更不可能搞定了。還是得開發人員上陣，按照美工給的模版，開始添加Css：class、id、style……

10：完成上面的開發，基本頁面的開發工作就完成了，最后的一個步驟就是把各個頁面有機的組織起來，開發應用程序的整體應用導航框架，通常就是菜單，然后把各個功能頁面跟菜單結合起來，形成一個完整的應用。

在這里我們省略了開發期反復的調試過程，僅總結開發的步驟。

選擇Web開發框架的目的

首先，沒有框架，我們需要做的工作是什么，了解了這些，我們才能更好的明白框架的價值。

框架，通俗地講，就是一個半成品，也就是組成一個機器的零件。目前我們使用的框架無論是基礎的底層框架，還是融合類型的付費框架，莫不如此。

而框架的選擇，要看項目的實際需求，底層框架適用于時間充裕的項目搭建，融合框架（快速開發框架）適用于短期項目，從成本上來說，通用型融合框架可以減少開發的工作量，提高工作效率，因為其本身已經融合了多種常用功能，ERP、OA、CRM、BI、甚至移動APP等，對企業來講，可操作性更強。

選擇Web開發框架的標準

標準不是一成不變的，這里也只是經驗之談，而且主要出發點在融合框架的業務功能方面，所以僅作參考之用。

1.選擇能夠對我們的開發過程提供更多、更好幫助的Web開發框架，功能性，穩定性要強。

2.Web開發框架的學習一定要簡單，上手一定要快，畢竟，沒有人愿意在復雜錯亂的框架結構中摸索，一個成熟的融合框架，如果需要半個月甚至一個月的學習周期，那這個框架確實有需要商榷的地方。

3.良好的技術支持。框架無論好壞，技術支持一定要做好，因為等你使用起來就明白，無論多好的框架，在實際的應用過程中，都會或多或少的出現問題，如果不能及時的解決，會對整個項目開發帶來影響。

此外，一定要考慮綜合成本，其實這是目前應用開源軟件最大的問題，碰到問題除了死肯文檔就是查閱源代碼，或者是網上搜尋解決的辦法，通常一個問題就會導致1-2天的開發停頓，嚴重的甚至需要一個星期或者更長，一個項目有上這么幾次，項目整體的開發成本嗖嗖的就上去了。

4.Web開發框架結合其他技術的能力一定要強，比如在邏輯層使用Spring或者Ejb3，同時框架整體也要很容易的與它們進行結合。

5.強大的拓展功能。就像剛才所說的，再好的框架都不可能做到面面俱到，況且每個企業的實際情況都有所不同，因此這就要求框架的拓展功能足夠強大，以滿足新業務的需求。但是，此處要注意一點，擴展一點要簡單，如果因為擴展功能而使框架整體功能受限，硬塞上去也是不合適的。

6.Web開發框架最好能提供可視化的開發和配置，可視化開發對開發效率的提高，已經得到業界公認，況且這一功能目前來說已經相對成熟，不多贅述。

7.Web開發框架的設計結構一定要合理，應用程序會基于這個框架，框架設計的不合理會大大影響到整個應用的可擴展性。

8.Web開發框架一定要能很好的結合目前公司的積累，可以有良好的項目對接。通常情況下，公司在多年的開發中已有了很多積累，不能因為使用Web開發框架就不能再使用了，那未免有些得不償失。

9.不要把框架想的神了。可以肯定的是，目前市面上的所有框架都不可能做到十全十美，也不可能適用所有應用場景，所以在選型前一定要了解它的適用范圍，判斷是否合適。