關(guān)于服務(wù)器與客戶端應(yīng)用程序渲染的討論很多。 雖然沒(méi)有“一刀切”的解決方案，但我將嘗試從不同的角度主張客戶端（特別是AngularJS）。 首先是建筑。

建筑

做得好的架構(gòu)已經(jīng)明確定義了關(guān)注點(diǎn)分離（SoS） 。 在大多數(shù)情況下，最少的高級(jí)配置為：

• 數(shù)據(jù)存儲(chǔ)
• 服務(wù)
• API
• 介紹

這些層中的每一層都應(yīng)僅具有上述知識(shí)的最少知識(shí)。 服務(wù)需要知道在哪里存儲(chǔ)數(shù)據(jù)，API需要知道要調(diào)用什么服務(wù)，并且表示層只能通過(guò)API與其余的服務(wù)進(jìn)行通信。 這里要注意的重要一點(diǎn)是，應(yīng)該不存在有關(guān)下面各層的知識(shí)。 例如，API不應(yīng)該知道誰(shuí)或什么消費(fèi)它。 它不應(yīng)該具有表示層的知識(shí)。

對(duì)于這些層中的每一層都應(yīng)該說(shuō)更多，“現(xiàn)實(shí)世界”中的情況要比這復(fù)雜得多。 但是，對(duì)于本文的其余部分，重要的要點(diǎn)是，表示層通過(guò)API與服務(wù)器進(jìn)行通信，而API對(duì)“外界”一無(wú)所知。 隨著越來(lái)越多的機(jī)器和設(shè)備類型（筆記本電腦，移動(dòng)設(shè)備，平板電腦，臺(tái)式機(jī)），這種分離變得越來(lái)越重要。 后端應(yīng)僅提供業(yè)務(wù)邏輯和數(shù)據(jù)。

技能專長(zhǎng)

考慮開發(fā)人員的技能是該體系結(jié)構(gòu)的重要方面。 例如，如果開發(fā)人員習(xí)慣于使用Java工作，則除非設(shè)計(jì)有明顯的優(yōu)勢(shì)，否則不應(yīng)該設(shè)計(jì)基于C＃的系統(tǒng)。 這并不意味著不應(yīng)使用新語(yǔ)言（誰(shuí)說(shuō)Scala和Clojure？）來(lái)提高技能。 只是必須考慮團(tuán)隊(duì)的生產(chǎn)力，并且編程語(yǔ)言的知識(shí)是重要的要素。

無(wú)論現(xiàn)有知識(shí)如何，應(yīng)用程序的類型都需要一些技能。 例如，如果應(yīng)用程序?qū)⒕W(wǎng)站作為表示層，則必須具有HTML，CSS和JavaScript知識(shí)。 有一些框架可以用來(lái)避免對(duì)該知識(shí)的需求（即Vaadin ）。 但是，這些框架的使用只會(huì)推遲不可避免的事情：接受HTML，CSS和JS是一種瀏覽器可以理解的語(yǔ)言。 問(wèn)題僅在于您是直接采用它們還是使用其他方式（即Java或C＃）為您編寫它們。 后一種情況可能會(huì)給人以更快的速度做事的印象，但是在許多情況下，當(dāng)需要做那些“翻譯”所不支持的事情時(shí)，需要付出一些代價(jià)。

服務(wù)器端更容易應(yīng)對(duì)。 對(duì)于每種技能，都有更多選擇，并且有好的（如果不是很好的話）解決方案。 我們可能會(huì)爭(zhēng)論Scala是否比Java更好，但是兩者都能提供足夠好的結(jié)果，并且學(xué)習(xí)新語(yǔ)言的決定要困難得多（盡管我認(rèn)為開發(fā)人員應(yīng)該通過(guò)嘗試新的語(yǔ)言和框架來(lái)不斷擴(kuò)展自己的知識(shí)）。 可以使用Java，Scala，C＃，Clojure，JavaScript / NodeJS等對(duì)后端進(jìn)行編碼。我們?cè)跒g覽器中沒(méi)有那么奢侈的地方。 Adobe Flash已死， Silverlight從未升空。 Vaadin之類的工具最初旨在緩解JavaScript帶來(lái)的痛苦，這是由于我們看到HTML和JavaScript的不斷改進(jìn)而逐漸失去了作用。 “瀏覽器”世界瞬息萬(wàn)變，情況與不久前大不相同。 歡迎來(lái)到HTML5的世界。

可以說(shuō)對(duì)于移動(dòng)設(shè)備的開發(fā)也是如此。 沒(méi)有一種語(yǔ)言能適合所有人。 我們無(wú)法使用Java開發(fā)iPhone應(yīng)用程序。 盡管在某些情況下HTML是解決方案，但在另一些情況下則需要進(jìn)行“本機(jī)”開發(fā)。

唯一的常數(shù)是，無(wú)論是Web，移動(dòng)設(shè)備，臺(tái)式機(jī)還是Google Glass ，它們都應(yīng)使用API??與系統(tǒng)的其余部分進(jìn)行通信。

我要提出的觀點(diǎn)是，在完成工作所需的語(yǔ)言采用與每個(gè)新項(xiàng)目中切換到新語(yǔ)言之間必須保持平衡。 有些語(yǔ)言是必須的，有些是很好的（但不是強(qiáng)制性的）。 使用Web時(shí)，HTML，CSS和JavaScript是必須的。

服務(wù)器與客戶端渲染

由于我們已經(jīng)確定，在網(wǎng)站（誰(shuí)說(shuō)應(yīng)用程序？）的情況下，帶有CSS和JavaScriptHTML是必須的，而試圖為我們創(chuàng)建HTML的工具是“邪惡的”，因此問(wèn)題仍然是誰(shuí)呈現(xiàn)HTML。 對(duì)于瀏覽器的大多數(shù)歷史記錄，我們習(xí)慣于在服務(wù)器中呈現(xiàn)HTML并將其發(fā)送給瀏覽器。 有很強(qiáng)的理由。 前端技術(shù)和框架還很年輕且不成熟，瀏覽器存在嚴(yán)重的兼容性問(wèn)題，并且通常來(lái)說(shuō)，使用JavaScript會(huì)很痛苦。 那張照片不再有效。 Google向我們展示了在許多情況下瀏覽器與臺(tái)式機(jī)一樣好。 JQuery通過(guò)讓我們以相對(duì)簡(jiǎn)單的方式來(lái)操作DOM，徹底改變了我們使用JavaScript的方式。 發(fā)布了許多其他的JS框架和庫(kù)。 但是，直到最近，還沒(méi)有什么可以替代舊的模型視圖控制器（MVC）模式。

對(duì)于所有小型站點(diǎn)，服務(wù)器呈現(xiàn)都是必須的。 還是？ AngularJS改變了我們感知MVC的方式（實(shí)際上，它是模型視圖的，但是我們不要被束之高閣）。 可以在客戶端中完成，而不會(huì)犧牲生產(chǎn)力。 我認(rèn)為，在許多情況下，隨著AngularJS生產(chǎn)率的提高。 還有其他客戶端MVC，例如BackboneJS和EmberJS 。 但是，就我的經(jīng)驗(yàn)來(lái)看，AngularJS沒(méi)有什么比這更好的了。

AngularJS并非沒(méi)有問(wèn)題。 讓我們看一下客戶端與服務(wù)器端頁(yè)面渲染的優(yōu)缺點(diǎn)。 在客戶端，我假設(shè)使用AngularJS。 為了進(jìn)行比較，服務(wù)器端可以是任何東西（Java，C＃等）。

AngularJS缺點(diǎn)

頁(yè)面呈現(xiàn)速度較慢，因?yàn)闉g覽器需要執(zhí)行DOM操作的額外工作，監(jiān)視綁定數(shù)據(jù)的變化，向服務(wù)器執(zhí)行其他REST請(qǐng)求等。第一次打開應(yīng)用程序時(shí)，它需要下載所有JavaScript文件。 根據(jù)應(yīng)用程序的復(fù)雜性，這可能是問(wèn)題，也可能不是問(wèn)題。 現(xiàn)代計(jì)算機(jī)完全有能力接管額外的工作。 移動(dòng)設(shè)備比舊計(jì)算機(jī)功能更強(qiáng)大。 在大多數(shù)情況下，客戶不會(huì)注意到瀏覽器需要做的工作量增加。

與舊版瀏覽器的兼容性很難實(shí)現(xiàn)。 需要在服務(wù)器上呈現(xiàn)其他頁(yè)面。 該參數(shù)的權(quán)重取決于您是否關(guān)心（非常）舊的瀏覽器。 罪魁禍?zhǔn)资荌nternet Explorer。 如果應(yīng)用了其他指令，則版本8可以工作（以某種方式）。 不支持早期版本。 將來(lái)的AngularJS版本將放棄對(duì)Internet Explorer 8的支持。您可以決定是否對(duì)IE8及更早版本的支持很重要。 如果是這樣，則需要提供替代頁(yè)面，這將導(dǎo)致額外的開發(fā)時(shí)間。 根據(jù)應(yīng)用程序的復(fù)雜性，非AngularJS開發(fā)中可能會(huì)存在相同的問(wèn)題。

搜索引擎優(yōu)化（SEO）可能是最大的問(wèn)題。 目前，緩解此問(wèn)題的最常用技術(shù)是在服務(wù)器上預(yù)渲染頁(yè)面。 這是一個(gè)相對(duì)簡(jiǎn)單的過(guò)程，需要少量代碼即可在任何屏幕上使用。 有關(guān)更多信息，請(qǐng)參見(jiàn)如何創(chuàng)建HTML快照？ 和Prerender.io 。 2014年5月，出現(xiàn)了一篇關(guān)于“了解網(wǎng)頁(yè)”的更好的文章，這給我們帶來(lái)了一個(gè)好消息，那就是Google能夠執(zhí)行JavaScript，從而解決（或正在解決）嚴(yán)重依賴JS的網(wǎng)站的SEO問(wèn)題。

AngularJS專業(yè)人士

如果性能良好（更好地使用JSON，客戶端緩存等）， 服務(wù)器性能將提高。 客戶端和服務(wù)器之間的通信量減少了。 服務(wù)器本身不需要在將頁(yè)面發(fā)送給客戶端之前創(chuàng)建頁(yè)面。 它只需要提供靜態(tài)文件并使用JSON響應(yīng)API調(diào)用。 減少了流量和服務(wù)器工作量。

AngularJS的設(shè)計(jì)考慮了測(cè)試需求。 連同依賴注入，模擬對(duì)象，服務(wù)和功能，編寫測(cè)試非常容易（比我所使用的大多數(shù)其他情況更容易）。 單元測(cè)試和端到端測(cè)試都可以編寫并快速運(yùn)行。

正如架構(gòu)部分所建議的，前端（幾乎）完全與后端分離 。 AngularJS需要了解REST API。 服務(wù)器仍然需要傳遞靜態(tài)文件（HTML，CSS和JavaScript），并在爬網(wǎng)程序訪問(wèn)時(shí)預(yù)渲染屏幕。 但是，這兩項(xiàng)工作不需要系統(tǒng)其余部分的任何內(nèi)部知識(shí)，并且可以在同一或完全不同的服務(wù)器上完成。 簡(jiǎn)單的NodeJS HTTP服務(wù)器可以達(dá)到目的。 這種解耦使我們可以獨(dú)立地開發(fā)后端和前端。 通過(guò)客戶端渲染，瀏覽器就像是Android，iPhone或桌面應(yīng)用程序一樣，是API使用者。

不需要服務(wù)器端編程語(yǔ)言的知識(shí)。 無(wú)論采用哪種方法（服務(wù)器或客戶端渲染），都需要HTML / CSS / JavaScript。 不將服務(wù)器端混入此圖中，將使前端開發(fā)人員的生活變得更加輕松。

Google對(duì)Angular的支持是一個(gè)加號(hào)。 像Google這樣的支持者更有可能繼續(xù)全力以赴地提供支持和未來(lái)的改進(jìn)。

一旦習(xí)慣了AngularJS的工作方式， 開發(fā)速度就會(huì)提高。 可以大大減少代碼量。 由于無(wú)需重新編譯后端代碼，因此我們幾乎可以立即看到前端的更改。

摘要

客戶端與服務(wù)器端渲染的這種視圖應(yīng)謹(jǐn)慎對(duì)待。 沒(méi)有“一刀切”的解決方案。 根據(jù)使用的需求和解決方案，上面列出的許多優(yōu)點(diǎn)和缺點(diǎn)都是無(wú)效的，或者也可以應(yīng)用于服務(wù)器端渲染。

在許多情況下，選擇服務(wù)器端渲染是為了避免陷入HTML，CSS和JavaScript。 它使習(xí)慣于使用服務(wù)器端編程語(yǔ)言（Java，C＃等）的開發(fā)人員更加輕松地認(rèn)為無(wú)需學(xué)習(xí)“瀏覽器”語(yǔ)言。 而且，在許多情況下，它會(huì)與后端代碼產(chǎn)生（通常是無(wú)意的）耦合。 兩種情況都應(yīng)避免。 我并不是說(shuō)服務(wù)器端渲染不可避免地會(huì)導(dǎo)致這些情況，而是使它們更有可能發(fā)生。

這是一個(gè)勇敢的新世界。 客戶端編程與以前完全不同。 至少有很多原因可以嘗試一下。 無(wú)論做出何種決定，都應(yīng)使用足夠的信息，只有通過(guò)實(shí)際經(jīng)驗(yàn)才能獲得這些信息。 嘗試一下，不要放棄第一個(gè)障礙（會(huì)有很多障礙）。 如果您選擇不采用此路線，請(qǐng)做出明智的決定。

像AngularJS這樣的客戶端MVC遠(yuǎn)非完美。 他們還比較年輕，還有很長(zhǎng)的路要走。 許多改進(jìn)即將到來(lái)，我堅(jiān)信Web的未來(lái)將朝著這個(gè)方向發(fā)展。

翻譯自: https://www.javacodegeeks.com/2014/07/server-vs-client-side-rendering-angularjs-vs-server-side-mvc.html

總結(jié)

以上是生活随笔為你收集整理的服务器与客户端渲染（AngularJS与服务器端MVC）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。