web開發|如何選擇合適的webui框架

 

　　在市場中很多人分不清框架和庫的區別，部分只知道框架模糊的概念。所以在選擇webUI框架的時候就會仁者見仁智者見智，會存在各抒己見也是很正常的，這裡整體都叫框架吧，在市場中不斷的淘汰與創新，主要以Vue、React和Angular三大底層框架為主，很多基於jQuery研發的框架在不斷的創新，也有和Vue、React和Angular三大框架並駕齊驅的框架出現。

這裡跟大家談談為什麼我們要使用webUI框架？

選擇Web UI框架的目的

瞭解瞭如果沒有框架，我們需要做的工作，這對選擇框架有非常大的幫助。 框架，直白點說，就是一個半成品，能夠幫我們做一些事情的半成品。 框架的選擇，就是看哪個框架最合適，從而減少開發的工作量，提高開發的效率和質量，並有效減少維護的工作量，最終達到節約綜合開發成本，獲取更多的收益。

選擇Web開發框架的標準

　　宣告：這裡所談的選擇WebUI框架的標準，只是我們的總結和一家之言，並不是放之四海而皆準的真理，請根據您的體會客觀的看待我們的總結。

　　另外：我們這裡更多的討論業務功能性應用程式的WebUI框架。

1：選擇能夠對我們的開發過程提供更多、更好幫助的Web開發框架

2：Web框架的學習一定要簡單，上手一定要快，沒有什麼比使用能得到更深的體會。那些動不動就需要半個月或者一個月學習週期的框架，實在是有些恐怖。

3：一定要能得到很好的技術支援，在應用的過程中，或多或少都會出現這樣或者那樣的問題，如果不能很快很好的解決，會對整個專案開發帶來影響。一定要考慮綜合成本，其實這是目前應用開源軟體最大的問題，碰到問題除了死肯文件就是查閱原始碼，或者是網上搜尋解決的辦法，通常一個問題就會導致1-2天的開發停頓，嚴重的甚至需要一個星期或者更長，一個專案有上這麼幾次，專案整體的開發成本嗖嗖的就上去了。

4：Web框架結合其他技術的能力一定要強

5：WebUI框架的擴充套件能力一定要強。在好的框架都有力所不及的地方，這就要求能很容易的擴充套件Web開發框架的功能，以滿足新的業務需要。同時要注意擴充套件的簡單性，如果擴充套件框架的功能代價非常大，還不如不用呢。

6：WebUI框架最好能提供視覺化的開發和配置，視覺化開發對開發效率的提高，已經得到業界公認。

7：Web框架的設計結構一定要合理，應用程式會基於這個框架，框架設計的不合理會大大影響到整個應用的可擴充套件性。

8：WebUI框架一定要是執行穩定的，執行效率高的。框架的穩定性和執行效率直接影響到整個系統的穩定性和效率。

9：WebUI框架一定要能很好的結合目前公司的積累。在多年的開發中已有了很多積累，不能因為使用Web開發框架就不能再使用了，那未免有些得不償失。

10：選擇開發框架另外要注意的一點就是：任何開發框架都不可能是十全十美的，也不可能是適應所有的應用場景的，也就是說任何開發框架都有它適用的範圍。所以選擇的時候要注意判斷應用的場景和開發框架的適用性。

使用框架的必然性

　　框架，即（framework）。其實就是某種應用的半成品，把不同應用程式中有共性的一些東西抽取出來，做成一個半成品程式，這樣的半成品就是所謂的程式框架。 軟體系統發展到今天已經很複雜了，特別是伺服器端軟體，涉及到的知識，內容，問題太多。在某些方面使用別人成熟的框架，就相當於讓別人幫你完成一些基礎工作，你只需要集中精力完成系統的業務邏輯設計。這樣每次開發就不用白手起家，而是可以在這個基礎上開始搭建。 使用框架的最大好處：減少重複開發工作量、縮短開發時間、降低開發成本。同時還有其它的好處，如：使程式設計更合理、程式執行更穩定等。基於這些原因，基本上現在在開發中，都會選用某些合適的開發框架，來幫助快速高效的開發應用系統。

Web層開發的工作

　　在開發中，分層是基本的思想，3層架構或者多層架構早已深入人心，在這裡我們就把目光集中到Web層，看看到底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：完成上面的開發，基本頁面的開發工作就完成了，最後的一個步驟就是把各個頁面有機的組織起來，開發應用程式的整體應用導航框架，通常就是選單，然後把各個功能頁面跟選單結合起來，形成一個完整的應用。

原文連結：http://www.uileader.com/news/news_content_88.html?id=88