Web前端發(fā)展及應(yīng)用

《Web前端發(fā)展及應(yīng)用》由會員分享，可在線閱讀，更多相關(guān)《Web前端發(fā)展及應(yīng)用（6頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 web 前端的發(fā)展及應(yīng)用 一、 簡單明了的早期時代 這個也稱為 web 1.0 時代，非常適合創(chuàng)業(yè)型不分前后端，經(jīng)常 3-5 個人就可以搞定所有的開 發(fā)，基本上是服務(wù)端給什么，瀏覽器就展現(xiàn)什么（由 web server 層控制） 好處： 簡單明了，本地起一個 Tomcat 或者 Apache 就能開發(fā)了， 只要業(yè)務(wù)不太復(fù)雜就都還

2、好。 弊端： 但業(yè)務(wù)太多了，變得復(fù)雜了， server 越來越多，開發(fā)人員增多時，就會遇到以下的一些問題 1. Service 越來越多，調(diào)用關(guān)系變復(fù)雜，前端搭建本地環(huán)境不再是一件簡單的事。 2. Jsp 等代碼的可維護(hù)性越來越差。 jsp:  非常強大，可以內(nèi)嵌 Java代碼。這種強大使得前后端的職責(zé)不清晰，  jsp 就變 成了一個灰色地帶，經(jīng)常會出現(xiàn)為了趕項目等各種緊急的需求，會在  jsp  里糅雜了 大量業(yè)務(wù)代碼，這種積攢到一定程度，往往會打來大量的維護(hù)成本。

3、 二．后端為主的 MVC 時代 為了降低復(fù)雜度，以后端為出發(fā)點，有了 web server 層的框架升級，這就是后端的 MVC 時 代。 從上面的圖可以看出來代碼的維護(hù)性得到了明顯的好轉(zhuǎn)， MVC 是個非常好的協(xié)作模式，從

4、 框架層面讓開發(fā)者懂得什么是代碼，應(yīng)該寫在什么地方，這使得模板里寫不了 Java 代碼， 但功能看起來變?nèi)趿?，正是這種限制使得了前后端分工更清晰，但任然會有問題存在： 1. 前端開發(fā)重度依賴開發(fā)環(huán)境 這種框架下， 前后協(xié)作有兩種模式： 一種是前端寫 demo，寫好后讓后端去套模板。 好處：很明顯， demo 可以本地開發(fā)，很高效，不足是還要后端套模板，有可能會套錯，而且還要前端確定，來回溝通調(diào)整的成本較大。 另一種協(xié)作的模式是前端負(fù)責(zé)瀏覽器的所有開發(fā)和服務(wù)器端的 view 層模板開發(fā)，支付寶是這種模式。 好處： UI 相關(guān)的代碼都是前端

5、去寫就好，后端不用太關(guān)注， 弊端：前端開發(fā)嚴(yán)重綁定后端的環(huán)境，環(huán)境成為影響前端開發(fā)效率的重要因素。 2. 前后端職責(zé)依舊糾纏不清 Velocity 模板還是挺強大的， 變量 邏輯，宏等特性， 依舊可以通過拿到上下文變量來實現(xiàn)各種業(yè)務(wù)邏輯。 這樣只要前端弱勢一點， 往往會被后端要求拿到的上下層寫 出不少業(yè)務(wù)代碼，還有一個灰色地帶是 controller ，頁面路由等功能應(yīng)該前端最關(guān)注的，但是由后端來實現(xiàn)了。 三 Ajax 的 SPA時代 2005 年 Ajax 正式提出，加上 CDN 開始大量用靜態(tài)資源儲存，于是就出現(xiàn)了 javascriptd

6、 的 SPA時代。 特點：這種模式下， 前后端的分工就非常清晰了， 前后端的關(guān)鍵協(xié)作點是 Ajax 接口，看起開 很好，但回頭看看，這與 jsp 時代區(qū)別不大。復(fù)雜程度從服務(wù)端的 jsp 里移到了瀏覽器得到 JavaScript，瀏覽器變得復(fù)雜，類似 Spring MVC ，這個時代開始出現(xiàn)瀏覽器端的分層架構(gòu)： 對于 SPA，有幾個重要的挑戰(zhàn) 1． 前后端接口的約定： 如果后

7、端的接口一趟糊涂，后端的業(yè)務(wù)模型不夠穩(wěn)定，那這樣前端開發(fā)會很痛苦。 2． 前端開發(fā)的復(fù)雜度調(diào)控： SPA應(yīng)用大多數(shù)以功能交互型為主， JavaScript 代碼過十萬行很正常。 大量 js 代碼的組織與 view 層的綁定等，都不是容易的事情。 四．前端為主的 MV* 時代 為了降低前端開發(fā)的復(fù)雜度，例如：

8、 好處： 1. 前后端職責(zé)很清晰： 前端在瀏覽器端工作，后端在服務(wù)端工作。 2. 前端開發(fā)的復(fù)雜問題可控： 前端代碼很重，但合理的分層，讓前端代碼各司其職。 3. 部署相對獨立： 產(chǎn)品可以快速改進(jìn)。 不足： 4. 代碼不能復(fù)用，例如后端依舊需要對數(shù)據(jù)做出各種校驗。 5. SPA不能滿足所有需求，依舊存在大量頁面應(yīng)用。 五． Node 帶來的全棧時代 前端

9、為主的 MV* 模式解決了很多很多問題，但依舊不足，然后 Node.js 興起了， JavaScript 開始有能力運行在服務(wù)端，這就研發(fā)了一種新的模式： 在這種情況下，前后端職責(zé)很清晰。對前端來說，兩個 UI 層各司其職： 1，F(xiàn)ront-end UI layer 處理瀏覽器層的展現(xiàn)邏輯。通過 C

10、SS渲染樣式，通過 JavaScript添加 交互功能， HTML 的生成也可以放在這層，具體看應(yīng)用場景。 2，Back-end UI layre 處理路由，模板，數(shù)據(jù)獲取等。通過路由，前端可以自主把控 URL Design，這樣無論是單頁面還是多頁面應(yīng)用，前端都可以自由調(diào)控，后端也可以擺脫對展現(xiàn)的強關(guān)注，可以專心于業(yè)務(wù)邏輯的開發(fā)。 與 JSP比較，全棧模式看起來是一種回歸，也的確是一種原始的開發(fā)模式的回歸，不過是一種螺旋上升的回歸。 Node 全棧時代面臨的挑戰(zhàn)： 1 需要前端對服務(wù)端編程有更進(jìn)一步的認(rèn)識 2 Node 層與 Java層的高效通信。 Node 模式下，都在服務(wù)器端 3 對部署，運維層面的熟練，需要更多知識點和實操經(jīng)驗。