Razor-based MVC vs. Одностраничное приложение в MVC 4

Я использовал механизм MVC 3 Razor для рендеринга страниц. Иногда мне приходилось использовать вызовы AJAX для передачи Razor-рендеринга HTML и вставки его на страницу с помощью JQuery. По мере того, как начинается новый проект, мы рассматриваем использование новой среды приложений MVC 4 Single Page Application, которая является новой для нас. Я впервые взглянул на него, что оставило меня со смешанными чувствами: С одной стороны, это означает, что все ваши данные передаются JSON, и клиент выполняет всю работу по их отображению и кодирует некоторую логику, связанную с UI, что отлично подходит для производительности сервера и сети. С другой стороны, клиент (HTML + JavaScript) становится намного более тяжелым с кучей волшебных строк и скрытых отношений внутри него, которые, похоже, трудно поддерживать. Мы привыкли к VS intellisense, титровально защищенному серверному коду .NET, чтобы отображать страницы, которые мы должны обменивать на клиентские скрипты и инструкции для нокаута в случае SPA.

Я удивляюсь, есть ли какие-либо предпосылки и минусы использования SPA по сравнению с Razor, другие - это очевидное, о котором я упомянул здесь? Благодаря

Ответ 1

Razor - это серверная технология, где SPA (одностраничное приложение) является архитектурным подходом, используемым на клиенте (веб-браузере). Оба могут использоваться вместе.

С высокого уровня, SPA перемещает рендеринг и извлечение данных клиенту. Веб-сервер становится уровнем обслуживания, сидящим перед базой данных. Шаблон MVC лучше всего работает при использовании SPA. Для этого можно использовать такие структуры, как Knockout.js и Backbone.js. Чистые результаты - это богатый отзывчивый рабочий стол, похожий на опыт.

Чтобы достичь этого, вам нужно быть программистом javascript спуска или быть готовым изучить javascript.

Да, он переводит бизнес-требования с С# на javascript. В Visual Studio существует ограниченный intelli-sense для javascript. Чтобы иметь уверенность в вашем javascript, вам нужно опираться на модульное тестирование. Наверху есть богатый пользовательский интерфейс (думаю, gmail или google maps).

Ответ 2

Я думаю, это звучит так, будто вы уже достаточно хорошо осведомлены о большинстве компромиссов здесь; вы уменьшите нагрузку на сеть с помощью SPA и переместите меру обработки клиенту. Тем не менее, вы увеличите сложность своего кода и сделаете его немного сложнее, чтобы легко поддерживать систему (просто из-за повышенной сложности - не из-за каких-либо архитектурных проблем, присущих SPA).

Еще одна вещь, о которой стоит помнить, - это совместимость. Причина, по которой я упомянул "ложный выбор" в моем комментарии к вашему вопросу, заключается в том, что для удобства использования сайта для людей с отключенным Javascript вам все равно необходимо будет предоставлять регулярные просмотры всей страницы. Это также хорошая идея сделать ради SEO; искатель будет просматривать ваш сайт в качестве пользователя с отключенным JS и затем индексировать ваш сайт. Затем сайт должен правильно обрабатывать такие входящие URL-адреса, чтобы те, у кого была включена JS, оказались в вашем SPA, глядя на один и тот же контент (в отличие от того, что они были без необходимости добавлены в "нет JS" ).

Что-то еще я упомяну как возможность, которая могла бы помочь в этом, но она нарушает идеалы SPA; то есть, используя частичные части, загруженные Ajax, в некоторых местах, а не данные JSON. Например, скажем, у вас есть типичная форма "Контактный EMail" на сайте; вы хотите, чтобы это загрузилось в контексте SPA, но, вероятно, это проще сделать, загрузив частичное через AJAX. (Хотя, конечно, да, вы можете сделать это с помощью объекта JSON, описывающего поля для отображения в форме электронной почты).

Вероятно, также будет контент, который больше "контента", чем "данные", который вы все еще можете загружать через частичные и Ajax.

SPA - это, безусловно, интересный проект, и я собираюсь его развернуть. Я использовал сочетание JSON и частичных в нем, но это может быть не по вашему выбору.