在服务器上渲染部分视图或在客户端上发送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图片就是该功能应该多快的一个很好的例子。 如果你知道你将永远不会拥有那么多数据，那么在服务器上呈现部分可能会更清晰，但如果你的需求发生变化，那么回到第一种方法是一件麻烦事。 简而言之，我认为第一种方法允许更多的灾难控制，只要加载大量数据需要多长时间。 我会说，尽管在开发人员的客户端有点不方便，但是尽可能在服务器上卸载服务器也是一般的好习惯。