（原作在www.webpagev.com)
開發框架的選擇，始終是個仁者見仁、智者見智的事情。尤其是Web層的開發框架，數量非常 |
| 多，而且各有特色，如：Struts、WebWork、Spring MVC、Tapestry、JSF、……等等。 |
| 下面先來看看為什么要使用Web開發框架 |
|
一：使用框架的必然性
|
| 框架，即framework。其實就是某種應用的半成品，把不同應用程序中有共性的一些東西抽取 |
| 出來，做成一個半成品程序，這樣的半成品就是所謂的程序框架。 |
| 軟件系統發展到今天已經很復雜了，特別是服務器端軟件，涉及到的知識，內容，問題太多。 |
| 在某些方面使用別人成熟的框架，就相當于讓別人幫你完成一些基礎工作，你只需要集中精力完成 |
| 系統的業務邏輯設計。這樣每次開發就不用白手起家，而是可以在這個基礎上開始搭建。 |
| 使用框架的最大好處：減少重復開發工作量、縮短開發時間、降低開發成本。同時還有其它的 |
| 好處，如：使程序設計更合理、程序運行更穩定等。基于這些原因，基本上現在在開發中，都會選 |
| 用某些合適的開發框架，來幫助快速高效的開發應用系統。 |
| 了解了使用框架的必然性，下面來看看如何選擇，當然我們的話題集中在Web層的開發框架。 |
| 在談這個問題之前，先來看看我們在Web開發中究竟需要做些什么工作： |
|
二：Web層開發的工作
|
| 在J2EE開發中，分層是基本的思想，3層架構或者多層架構早已深入人心，在這里我們就把目光 |
| 集中到Web層，看看到底Web層開發做了那些工作： |
| 1：數據展示 |
| Web層需要從邏輯層獲取需要展示的數據，然后以合理的方式在頁面進行展示 |
| 2：人機交互 |
| 用戶需要從界面上輸入數據，在界面上進行按鈕點擊，進而觸發事件，標準的事件驅動模型， |
| 然后跟后臺進行數據交換，出現新的界面。 |
| 3：收集數據，調用邏輯層接口 |
| Web層收到用戶的事件請求，需要調用相應的邏輯層接口來進行處理，Web層是不會有任何邏輯 |
| 處理的。調用邏輯層接口，需要傳遞參數，這時需要收集用戶在界面上輸入的數據，然后進行組 |
| 織，組織成為邏輯層接口需要的數據封裝形式（通常都是ValueObject）。 |
| 4：根據邏輯層的數據來重新展示頁面 |
| 邏輯層處理完了，需要返回數據或信息到界面上。這個時候Web層需要根據返回的值選擇合適的 |
| 頁面，然后展示這些數據或者信息。 |
從上面可以看出，Web層開發的主要工作集中在展示上，也就是圖形用戶界面。這一部分是用戶 |
| 直觀感受應用程序的窗口，也是用戶要求最多的地方，其表現形式也是最豐富的。 |
|
三：Web層開發的步驟
|
| 下面再來總結一下Web層開發的大致步驟（也就是需要開發人員做的工作）： |
| 注意：這里討論的Web層開發，是不使用任何開發框架時候的開發。 |
| 1：寫頁面Html，到底有哪些數據需要在界面上表現 |
| 2：每個數據的具體表現形式，如：有的需要表現成為下拉列表，有的需要表現成為單選按鈕等。 |
| 3：界面表現形式的邏輯布局，所謂邏輯布局是指某些數據的表現形式應該放在前面，某些應該放在 |
| 后面；某些放在上面，某些放在下面。如：某個請假申請的業務，有請假開始時間和結束時間， |
| 很明顯開始時間的表現就應該排在結束時間的前面。而美工是負責最后頁面的美觀，一般美工不能 |
| 動界面的邏輯布局。 |
| 4：完成前面3步，頁面的表現形式的大致模樣就有了，下面需要來做功能性的開發。第一個就是 |
| 這些表現形式的值的來源，如：下拉列表顯示的值從什么地方來。值的來源方式很多，有數據庫中 |
| 來、固定值、某斷程序運行的中間結果、前面頁面傳遞過來等等，當然典型的還是來自數據庫。 |
| 好了，確定了值的來源，開發人員就要寫代碼來獲取這些值，然后把這些值賦值到對應的表現形式里面。 |
| 5：還有一些比較特殊，也就是真實操作的是一類值，但是在界面上顯示的是另一類值，比如：數據 |
| 庫中有用戶編號，到了界面上就得顯示用戶姓名，但是所有的操作都是要操作用戶編號的。我們把 |
| 這種情況分做：真實值和表現值，他們有一定的內在聯系。這些都是要開發人員去轉化和維護的。 |
| 6：接下來就應該開發功能性的事件響應了。用戶點擊了某個按鈕或者觸發了某個事件，首先是客戶 |
| 端：數據檢測、客戶端事件處理；然后提交到服務端，服務端要獲取到客戶端提交的數據，然后調 |
| 用相應的邏輯層接口來響應。當然如何寫邏輯層的實現這里就不去談論了。 |
| 7：邏輯層執行完過后，返回數據和信息到Web層，開發人員還需要寫代碼去處理，選擇哪個頁面來顯 |
| 示，如何顯示這些數據和信息等。 |
| 8：在整個交互的過程中，還必須考慮到如何控制權限，如：某些數據不能顯示，某些數據不能編輯等 |
| 等；同樣還需要考慮到消息的配置和國際化等等。這些功能起源于邏輯層，但是實際的控制要到Web層， |
| 這些都需要開發人員來控制。 |
| 9：完成了上面的開發步驟，頁面基本的功能開發就告一段落，接下來開發人員需要考慮頁面美觀的問題 |
| 了。大家可能會說：“不是有美工嗎，還需要開發人員干什么？”。事實上美工多半只能出一個靜態頁 |
| 面的美化模版，美工對于一推Java代碼和Html的混雜物，多半是沒有辦法的，更不要說還有一些內容是 |
| 動態生成的，美工就更不可能搞定了。還是得開發人員上陣，按照美工給的模版，開始添加Css：class、id、style…… |
| 10：完成上面的開發，基本頁面的開發工作就完成了，最后的一個步驟就是把各個頁面有機的組織起 |
| 來，開發應用程序的整體應用導航框架，通常就是菜單，然后把各個功能頁面跟菜單結合起來，形成 |
| 一個完整的應用。 |
| 在這里我們省略了開發期反復的調試過程，僅總結開發的步驟。 |
|
四：選擇Web開發框架的目的
|
| 了解了如果沒有框架，我們需要做的工作，這對選擇框架有非常大的幫助。 |
| 框架，直白點說，就是一個半成品，能夠幫我們做一些事情的半成品。 |
| 框架的選擇，就是看哪個框架最合適，從而減少開發的工作量，提高開發的效率和質量，并有效 |
| 減少維護的工作量，最終達到節約綜合開發成本，獲取更多的收益。 |
|
五：選擇Web開發框架的標準
|
| 聲明：這里所談的選擇Web開發框架的標準，只是我們的總結和一家之言，并不是放之四海而皆準的 |
| 真理，請根據您的體會客觀的看待我們的總結。 |
| 另外：我們這里更多的討論業務功能性應用程序的Web開發框架。 |
| 1：選擇能夠對我們的開發過程提供更多、更好幫助的Web開發框架 |
| 2：Web開發框架的學習一定要簡單，上手一定要快，沒有什么比使用能得到更深的體會。那些動不動 |
| 就需要半個月或者一個月學習周期的框架，實在是有些恐怖。 |
| 3：一定要能得到很好的技術支持，在應用的過程中，或多或少都會出現這樣或者那樣的問題，如果不能 |
| 很快很好的解決，會對整個項目開發帶來影響。一定要考慮綜合成本，其實這是目前應用開源軟件最大 |
| 的問題，碰到問題除了死肯文檔就是查閱源代碼，或者是網上搜尋解決的辦法，通常一個問題就會導致 |
| 1-2天的開發停頓，嚴重的甚至需要一個星期或者更長，一個項目有上這么幾次，項目整體的開發成本 |
| 嗖嗖的就上去了。 |
| 4：Web開發框架結合其他技術的能力一定要強，比如：在邏輯層要使用Spring或者Ejb3，那么Web開發 |
| 框架一定要能很容易，很方便的與它們進行結合。 |
| 5：Web開發框架的擴展能力一定要強。在好的框架都有力所不及的地方，這就要求能很容易的擴展Web |
| 開發框架的功能，以滿足新的業務需要。同時要注意擴展的簡單性，如果擴展框架的功能代價非常大， |
| 還不如不用呢。 |
| 6：Web開發框架最好能提供可視化的開發和配置，可視化開發對開發效率的提高，已經得到業界公認。 |
| 7：Web開發框架的設計結構一定要合理，應用程序會基于這個框架，框架設計的不合理會大大影響到 |
| 整個應用的可擴展性。 |
| 8：Web開發框架一定要是運行穩定的，運行效率高的。框架的穩定性和運行效率直接影響到 |
| 整個系統的穩定性和效率。 |
| 9：Web開發框架一定要能很好的結合目前公司的積累。在多年的開發中已有了很多積累，不能因為 |
| 使用Web開發框架就不能再使用了，那未免有些得不償失。 |
| 10：選擇開發框架另外要注意的一點就是：任何開發框架都不可能是十全十美的，也不可能是適應所有 |
| 的應用場景的，也就是說任何開發框架都有它適用的范圍。所以選擇的時候要注意判斷應用的場景和 |
| 開發框架的適用性。 |