在服務器上渲染部分視圖或在客戶端上發送json數據和渲染模板

Question

我想知道在Web應用程序中渲染部分視圖的好方法（或推薦方法）。

我有一個要求，我需要使用AJAX將數據加載到已經呈現的頁面中，有點像頁面末尾的“加載更多...”鏈接，它從服務器獲取更多信息並將其呈現到底部這頁紙。

我正在玩AJAX響應的兩個選項是

1. 返回數據的JSON表示，並使用客戶端模板庫（例如jQuery模板）或只是簡單的javascript將JSON轉換為HTML並附加到頁面底部
2. 渲染服務器上的局部視圖（在我的例子中使用grails' render template:'tmplt_name' ）並通過網絡發送它，只需將結果附加到頁面底部

還有其他方法嗎？ 如果沒有，鑒於上述選項在維護，性能和可測試性方面會更好？ 我確定的一件事是，JSON路由（在大多數情況下）比使用線路發送html消耗更少的帶寬。

Answer 1

這實際上是一個非常有趣的問題，因為它暴露了一些有趣的設計決策。

我更喜歡渲染部分模板，因為它使我的應用程序能夠隨時間變化。 如果我需要使用圖表從<table>更改為<div> ，則可以很容易地將其封裝在模板中。 考慮到這一點，我將幾乎每個頁面視為許多小模板的集合，這些模板可能會發生變化。 Grails 2.0默認的腳手架已經轉向這種方法，這是一個好主意。

關於它們應該是客戶端模板還是服務器端的問題是問題的症結所在。

服務器端模板可在初始頁面加載時保持標記清晰。 即使你使用類似於ICANHazJS的 Mustache之類的東西 ，你也需要在頁面中有一個空元素（與你的模板有關），適當地設置它，並在Javascript中使用它以便更新你的信息。

缺點

• “聊天”應用程序
• 電線上的較大信封（響應包括HTML，可能被視為靜態）
• UI響應時間較慢

優點

• 適合擁有大量服務器端語言經驗的人士
• 可能更容易在服務器端環境中操作或修改（例如，返回嵌入了多個模板的頁面，這些模板以編程方式加載並包含在內）
• 將大部分應用程序內容保存在“一個地方”

但是，客戶端模板確實可以減少服務器負載。 它們使應用程序“不那么”，因為可能通過發送更大的JSON集合（在相同的字節數或更少的數量，將由HTML占用）來最小化返回服務器的調用次數。服務器端模板方案）。 它們還為用戶提供了非常快的UI體驗，因為點擊“更新”鏈接不需要進行AJAX往返。 有人說：

Anthony Eden @aeden 10月12日回復轉推收藏·打開網絡應用的未來：請求由功能處理，邏輯始終是異步的，並且從不在服務器上生成HTML。

缺點

• 對於SEO（初始頁面加載時無語義無關的UI元素）不太好
• 需要一些Javascript foo（操縱元素）

優點 - 響應 - 更小的信封

趨勢似乎正朝着客戶端模板發展，特別是HTML5添加功能（如<canvas> ）暴露出來......但如果利用它們，則需要依靠您不熟悉的技術，讓您感覺更舒服使用Grails partials，可能值得從這些開始，並根據性能和其他問題調查​​客戶端模板的重構。

Answer 2

在我的視圖中，第二個選項呈現部分更好，因為如果你得到一個json數據，你應該像設置樣式一樣操作它，創建元素，設置值和類似的東西，只需在javascript中獲得ajax響應后，但如果你渲染局部，你可以在之前設計你的視圖並保持准備就緒，只需使用ajax調用導入，這樣就沒有責任處理響應數據了。

Answer 3

我會說這取決於你在發送時通過網絡發送了多少數據。 如果您正在實現“加載更多”功能，那么您似乎不想花5秒鍾來加載某些內容。 Google圖片就是該功能應該多快的一個很好的例子。 如果你知道你將永遠不會擁有那么多數據，那么在服務器上呈現部分可能會更清晰，但如果你的需求發生變化，那么回到第一種方法是一件麻煩事。 簡而言之，我認為第一種方法允許更多的災難控制，只要加載大量數據需要多長時間。 我會說，盡管在開發人員的客戶端有點不方便，但是盡可能在服務器上卸載服務器也是一般的好習慣。