企業資訊平臺的快速搭建，框架如何選？

  Web端開發框架如何選

目前，大部分的企業資訊整合系統都在web端執行，而搭建框架的選擇對一個企業的發展至關重要，不過其最終目的都是要符合企業發展邏輯，助力企業戰略的實施。

而在框架的選擇上就是一個仁者見仁的事情了，就從底層框架來說，web層的就非常多，而且各有特色，比如：Struts、WebWork、Spring MVC、Tapestry、JSF、WebPage3.0……等等。

那麼為什麼要使用框架呢？

使用框架的必然性

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

 這裡給大家推薦一款我公司使用的敏捷開發框架learun，謹作選型參考，免費體驗地址：