Клиент ASP.NET и серверный рендеринг

Question

Использование ASP.NET MVC: я попал в середину между рендерингом своих представлений на сервере и клиентом (скажем, в шаблонах jquery).Мне не нравится идея смешивания двух, как я слышу, некоторые люди говорят.Например, некоторые сказали, что они будут отображать начальную страницу (скажем, список комментариев) на стороне сервера, а затем, когда добавляется новый комментарий, они используют шаблоны на стороне клиента.Требование иметь одинаковую логику рендеринга в двух разных областях вашего кода заставляет меня задуматься, как люди убеждают себя, что оно того стоит.

По каким причинам вы решаете, где и где использовать?

Как изменяется ваш аргумент при использовании веб-форм ASP.NET?

Answer 1

Одна из причин, по которой люди делают это, заключается в том, что они хотят, чтобы их сайты индексировались поисковыми системами, но также хотят иметь лучший пользовательский интерфейс, поэтому пишем для этого клиентский код.Вы должны решить, что имеет смысл, учитывая ваши ограничения и цели.К сожалению, то, что имеет наибольшую деловую значимость, не всегда кажется наиболее значимым с технической точки зрения.

Answer 2

Одним из преимуществ рендеринга на стороне сервера является то, что вашим клиентам не нужно использовать javascript, чтобы ваши страницы работали. Если вы полагаетесь на шаблоны JQuery, вы в значительной степени должны предположить, что на вашей странице не будет никакого контента при визуализации без javascript. Для некоторых людей это важно.

Как вы говорите, я бы предпочел не использовать одну и ту же логику рендеринга дважды, поскольку вы рискуете нарушить ее синхронизацию.

Я обычно предпочитаю просто использовать частичные представления для создания большей части контента на стороне сервера. Страницы с прямым HTML имеют тенденцию отображаться немного быстрее, чем страницы, которые необходимо «построить» после загрузки, что делает начальную загрузку немного быстрее.

Мы разработали архитектуру AJAX на основе событий для нашего приложения, которая позволяет нам генерировать фрагмент содержимого в ответ на результат действия и, по сути, отправлять любое количество команд клиентскому коду, чтобы сказать «Используйте результаты этого визуализированного частичного представления для замены элемента с идентификатором« X »» или «Откройте новое модальное всплывающее диалоговое окно с этим в качестве содержимого». Это выгодно, потому что код на стороне сервера может иметь гораздо больший контроль над результатами AJAX-запроса, без необходимости писать код на стороне клиента для обработки каждого непредвиденного обстоятельства для каждого действия.

С другой стороны, такой контроль сервера означает, что запрос должен быть возвращен до того, как клиентская сторона знает, что делать. Если рендеринг вашего представления был в значительной степени основанным на клиенте, вы могли бы сделать что-либо «происходящим» в пользовательском интерфейсе (например, вставив новый комментарий туда, куда он идет) немедленно, тем самым улучшив «воспринимаемую скорость» вашего сайта. Кроме того, интернет-соединение, как правило, является узким местом для большинства веб-сайтов с точки зрения скорости, поэтому наличие меньшего количества данных (JSON) для отправки по проводам часто может ускорить процесс. Поэтому для элементов, которые я хочу очень плавно реагировать на взаимодействие с пользователем, я часто использую рендеринг на стороне клиента.

В прошлом поисковая оптимизация была большой проблемой и здесь, как говорит Джарретт Видман. Но я понимаю, что большинство современных поисковых систем достаточно умны, чтобы оценить исходный javascript для страниц, которые они посещают, и выяснить, как будет выглядеть страница после загрузки. Google даже рекомендует использовать «shebang» в ваших URL, чтобы помочь им узнать, как индексировать страницы, которые динамически загружаются AJAX.