ASP.NET 客户端与服务器视图渲染
使用 ASP.NET MVC：我陷入了在服务器上渲染视图和在客户端上渲染视图（例如 jquery 模板）之间的困境。我不喜欢将两者混合的想法，正如我听到一些人说的那样。例如，有些人表示他们将在服务器端渲染初始页面（例如一堆评论的列表），然后当添加新评论时，他们使用客户端模板。在代码的两个不同区域具有相同渲染逻辑的要求让我想知道人们如何说服自己这是值得的。
您决定在何处使用哪个的原因是什么？
使用 ASP.NET Web 窗体时，您的论点有何变化？
Using ASP.NET MVC: I am caught in the middle between rendering my views on the server vs in the client (say jquery templates). I do not like the idea of mixing the two as I hear some people say. For example, some have said they will render the initial page (say a list of a bunch of comments) server side, and then when a new comment is added they use client side templating. The requirement to have the same rendering logic in two different areas of your code makes me wonder how people convince themselves it is worth it.
What are the reasons you use to decide which to use where?
How does your argument change when using ASP.NET Web Forms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
人们这样做的原因之一是因为他们希望自己的网站被搜索引擎索引，但也希望获得最佳的用户体验，因此正在为此编写客户端代码。考虑到您所拥有的限制和目标，您必须决定什么是有意义的。不幸的是，从技术角度来看，最具商业意义的东西似乎并不总是最有意义的。
One reason that people do that is because they want their sites to get indexed by search engines but also want to have the best user experience, so are writing client code for that. You have to decide what makes sense given the constraints and goals you have. Unfortunately, what makes the most business sense won't always seem to make the most sense from a technical perspective.
服务器端呈现的优点之一是您的客户端不必使用 JavaScript 即可使您的页面正常运行。如果您依赖 JQuery 模板，那么您几乎必须假设您的页面在没有 JavaScript 的情况下呈现时不会有任何内容。对于某些人来说这很重要。
正如你所说，我不想两次使用相同的渲染逻辑，因为你冒着让它不同步的风险。
我通常更喜欢仅利用部分视图来生成服务器端的大部分内容。具有直接 HTML 的页面往往比加载后必须“构建”的页面呈现得更快一些，从而使初始加载速度更快一些。
我们为我们的应用程序开发了一个基于事件的 AJAX 架构，它允许我们生成一段内容来响应操作的结果，并实质上向客户端代码发送回任意数量的命令来表示“使用此呈现的部分视图的结果，以替换 ID 为“X”的元素”，或“打开一个新的模式弹出对话框，以此作为内容。”这是有益的，因为服务器端代码可以对 AJAX 请求的结果有更多的控制，而不必编写客户端代码来处理每个操作的每种意外情况。
另一方面，像这样让服务器控制意味着请求必须在客户端知道要做什么之前返回。如果您的视图渲染主要基于客户端，您可以立即在 UI 中“发生”一些事情（例如在其所在的位置插入新评论），从而提高网站的“感知速度”。此外，互联网连接通常是大多数网站的真正速度瓶颈，因此只需通过网络发送较少的数据 (JSON) 通常就可以使速度更快。因此，对于我想要非常流畅地响应用户交互的元素，我经常使用客户端渲染。
正如 Jarrett Widman 所说，过去，搜索引擎优化也是一个大问题。但我的理解是，大多数现代搜索引擎都足够聪明，可以评估它们访问的页面的初始 JavaScript，并弄清楚页面加载后的实际外观。 Google 甚至建议使用“shebang” 在您的 URL 中，帮助他们了解如何索引由 AJAX 动态加载的页面。
One advantage to server-side rendering is that your clients don't have to use javascript in order for your pages to be functional. If you're relying on JQuery templates, you pretty much have to assume that your page won't have any content when rendered without javascript. For some people this is important.
As you say, I would prefer not to use the same rendering logic twice, since you run the risk of letting it get out of sync.
I generally prefer to just leverage partial views to generate most content server-side. Pages with straight HTML tend to render a bit faster than pages that have to be "built" after they've loaded, making the initial load a little speedier.
We've developed an event-based AJAX architecture for our application which allows us to generate a piece of content in response to the result of an action, and essentially send back any number of commands to the client-side code to say "Use the results of this rendered partial view to replace the element with ID 'X'", or "Open a new modal popup dialog with this as the content." This is beneficial because the server-side code can have a lot more control over the results of an AJAX request, without having to write client-side code to handle every contingency for every action.
On the other hand, putting the server in control like this means that the request has to return before the client-side knows what to do. If your view rendering was largely client-based, you could make something "happen" in the UI (like inserting the new comment where it goes) immediately, thereby improving the "perceived speed" of your site. Also, the internet connection is generally the real speed bottleneck of most websites, so just having less data (JSON) to send over the wire can often make things more speedy. So for elements that I want to respond very smoothly to user interaction, I often use client-side rendering.
In the past, search-engine optimization was a big issue here as well, as Jarrett Widman says. But my understanding is that most modern search engines are smart enough to evaluate the initial javascript for pages they visit, and figure out what the page would actually look like after it loads. Google even recommends the use of the "shebang" in your URLs to help them know how to index pages that are dynamically loaded by AJAX.