用JavaScript編寫業務邏輯？

2016/07/13 來源：CSDN博客

Thinking in JavaScript（12）

Web應用程式剛剛興起並取代傳統客戶端應用程式時，技術熱點在伺服器端開發語言。從ASP、PHP到Java、ASP.NET，無論採用哪種技術，作為一個系統核心的業務邏輯都是用一種運行在伺服器端的語言編寫的。架構師習慣將一個應用系統分為多層，視圖層、業務邏輯層和數據層等，而它們也都是以某種伺服器端程式語言，結合html和sql等技術，在伺服器上運行。JavaScript作為運行在瀏覽器中的語言，僅僅是用來完成校驗、界面的零散修改等任務。那時候誰要是提出用這種輔助性的語言來編寫業務邏輯，一定會被當成天方夜譚。然而時光流轉，技術發展，Web系統越來越倚重JavaScript。JavaScript語言的能力和特性被徹底發掘，Ajax成為Web開發的常規，JavaScript框架層出不窮日新月異，昔日的天方夜譚越來越多變成現實。利用某個MVC模式的JavaScript框架，業務邏輯代碼運行在瀏覽器中，通過RESTful服務和伺服器交換數據，是越來越多功能豐富、外觀華麗的Web應用的技術路徑，推向極致便是所謂的單頁面應用。

在這種趨勢下，一個必然會產生的問題就是業務邏輯真的應該全部從伺服器端移到瀏覽器端嗎？
好處：
1. 更快的響應。Web應用系統響應所費的時間一大部分是用在網絡傳輸上。傳統的Web應用每當要執行業務邏輯時，哪怕是很簡單的計算，都要提交到伺服器，再等待返回整個頁面。等到後來採用Ajax技術，伺服器端可以只返回執行業務邏輯後的數據結果，性能就大大提高。更進一步地，如果一開始就將應用的模型數據傳輸到瀏覽器，後續的計算都用JavaScript完成，只有當需要更新資料庫時才返回到伺服器，網絡傳輸就更少，系統響應也就更快。而且，應用程式會用到一些無需持久化保存的臨時數據，比如和界面顯示相關的或者計算時用到的中間數據，對這些數據的運算也都無需在伺服器端進行再傳輸到瀏覽器。這些因素的共同作用就使得Web應用在很多時候的響應速度可以達到本地應用的水平。
2. 更簡單的結構。一項功能通常既包括看不見的運算，也包括用戶界面的變化。如果以傳統的方式來實現，伺服器端代碼進行業務邏輯的計算，將結果傳輸到瀏覽器，JavaScript再修改html完成顯示上的變化，分別用兩種語言編寫，伺服器端發送數據前的編碼和瀏覽器端接送數據後的解碼也都需要專門的工作。將業務邏輯轉移到瀏覽器端用JavaScript編寫則會讓代碼變得更一致，結構更簡單。
3. 更好的伸縮性。代碼分散到各個用戶的電腦上執行，自然減少了伺服器的負荷。

壞處：
1. 用戶環境的不確定性。不同用戶的電腦配置、瀏覽器種類會給應用程式的表現帶來不確定性。雖然說「萬一用戶禁止JavaScript運行怎麼辦？」這樣的憂慮在如今顯得有些杞人憂天，但JavaScript運行速度、瀏覽器對腳本的支持乃至緩存問題等用戶環境上的差異導致的不確定性比起代碼集中在可控的伺服器端運行還是大得多。
2. 代碼的隱私性和安全性。用JavaScript編寫業務邏輯代碼意味著你的系統暴露在大庭廣眾之下。除卻安全性上的顧慮，單單曝露於眾這一點，就會讓長期以來習慣於要保護代碼智慧財產權、千方百計隱蔽、加密、混亂化代碼的軟體公司和程式設計師覺得彆扭，和失去隱私的感覺一樣。不僅如此，伺服器端的數據接口也變得外人可見，因而它們編寫的安全性也需要提高。
3. JavaScript。這一點實際上是見仁見智的。JavaScript與伺服器端語言Java、C#、Python、PHP比起來是不是適合用於編寫業務邏輯的複雜代碼，你是討厭它的沒有編譯時檢查、難於調試測試、語言設計上的缺陷還是喜歡它的簡潔、靈活、函數式編程？這一點或許是對於一個程式設計師來說，採用新舊哪種開發模式的決定因素。

曾經的客戶端應用程式，被稱為胖客戶端，以此對比Web系統所用的瀏覽器是瘦客戶端。風水輪流轉，如今隨著一個系統中越來越多的代碼用JavaScript編寫，瀏覽器又逐步變成富客戶端。然而背後的動因和邏輯都是一樣的，那就是用戶是上帝。前一次轉換是為了省去用戶安裝和更新的時間，後一次轉換是為了讓用戶享受到更快的速度和豐富的功能。在手機開發領域，模式乾脆又回到了客戶端——App，因為本地運行的App不僅速度更快、可以離線運行，還能調用攝像頭、地理位置、話筒聽筒等手機硬體功能，總之就是讓用戶有更好的體驗，而這背後的程式設計師們則或者啃書本更新技能，或者長江後浪推前浪。

免責聲明：本文內容來源于CSDN博客，文章觀點不代表壹讀立場，如若侵犯到您的權益，或涉不實謠言，敬請向我們提出檢舉。