Имеет ли смысл интегрировать backbone.js с ASPNET MVC?

Я не эксперт в этих строительных блоках, но на первый взгляд мне кажется:

ASPNET MVC хочет генерировать представления и управлять моделями для приложения на стороне сервера. Он рассматривает браузер как несколько немой механизм представления, потребитель из представлений, предоставляемых ему сервером.
backbone.js хотел бы генерировать представления и управлять моделями в браузере. Он рассматривает серверную сторону как довольно немой механизм устойчивости на основе REST.

Это похоже на упрощенное представление. Я уверен, что это не вся история.

Каковы реальные возможности для интеграции этих двух вещей? Имеет ли смысл делать это? Или существует слишком много перекрытий между ними, чтобы это имело смысл?

Мне нравится видеть какой-то анализ или обсуждение этого вопроса, если кто-то может направить меня.

Ответ 1

Пока я не могу разговаривать с backbone.js, могу сказать, что я использовал нокаутом для отличного эффекта в сочетании с ASP.NET MVC. Каждое приложение ASP.NET, которое я видел на сегодняшний день, использует сочетание клиентского и серверного представления. Всегда найдутся моменты, когда более удобно генерировать представления на стороне сервера. Возьмем, например, условные элементы пользовательского интерфейса на основе того, аутентифицирован ли пользователь или нет ли у них определенного разрешения. Возможно, вы не захотите, чтобы веб-опытный пользователь мог изучить ваши шаблоны на стороне клиента и разработать все функции, которые они не получают. Конечно, вы можете обойти это путем асинхронной загрузки различных клиентских шаблонов, бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бла-бета или для создания клиентских кодов для создания ваших клиентских шаблонов... Кроме того, если SEO что-то означает для вас, вы можете поцеловать шаблоны на стороне клиента ( прощай.

Итак, сладкое пятно, на мой взгляд, - это то, что хорошо и хорошо. По моему опыту, я нашел ASP.NET MVC, чтобы преуспеть в обоих.

Почему ASP.NET MVC является удивительным

Макеты (MasterPages)
Бритва (безопасные по типу виды с добротой intellisense)
ActionFilters (удивительное место для применения таких конвенций, как ведение журнала, auth и т.д.)
Сериализация JSON бесплатно - return Json(model)
Связывание и проверка модели
IoC и MVC - лучшие друзья (победа)
Аутентификация + авторизация
Много других вещей, о которых я не могу думать.

Используя клиентскую инфраструктуру для создания представлений, на самом деле все, что вам не хватает, это Razor. Вы даже можете использовать макеты в некоторой степени.

Подход, который я принимаю к разработке с помощью ASP.NET MVC, должен начинаться с того, что приложение работает на стороне сервера. Это заставляет вас думать о том, что вам нужна ваша структура URL, что заслуживает контроллера, какими должны быть ваши маршруты. Это также означает, что вы получаете преимущества безопасности типов и автозаполнения во время первой итерации просмотров. В конце этого упражнения у вас есть простое, совместимое со стандартами решение (надеюсь), которое работает на любом известном человеку устройстве, которого Google не может получить достаточно.

Затем я начал применять постепенный подход к реализации срезов клиентской функциональности. На стороне клиента я пишу несколько javascript, чтобы захватить запрос, который я хочу превратить в запрос AJAX, и обработать ответ, используя переведенную версию вида Razor. На стороне сервера я использую подход на основе соглашения с использованием фильтра действий. Этот фильтр действий выполняет примерно следующее:

Является ли ActionResult ViewResult?
- Что такое тип Accept?
  - HTML - Возвращает PartialViewResult с тем же именем, с префиксом "_", с той же моделью
  - JSON - возвращает JsonResult с той же моделью
Является ли ActionResult результатом RedirectToRoute?
- Возвращает EmptyResult (или, возможно, вы можете вернуть URL-адрес в JsonResult)

При таком подходе вы можете добавить функциональность AJAX без изменения одной строки кода в контроллерах. Альтернативный подход заключается в том, чтобы следовать Принципу Thunderdome и иметь ActionInvoker, ответственный за упаковку модели в соответствующем типе результата на основе контекста запроса. Я не разработал, как навигация на стороне сервера (переадресация) подходит для этого подхода.

Отходы, начинающиеся с реализации на стороне сервера, - это удвоение кода представления кода (шаблон Razor + js). В зависимости от того, сколько вашего приложения вы хотите реализовать на клиенте, это может быть или не быть проблемой. Spark является исключением из этого в том, что вы действительно можете получить его создать клиентские шаблоны для вас! Недостатком Spark является то, что вы теряете intellisense (там плагин для него, но его дерьмо), который не является незначительной потерей, плюс я просто предпочитаю Razor (его испекли, не нужно настраивать и не уходит в любое время в ближайшее время).

Ответ 2

Я использовал asp.net mvc KO и bakcbone для разных проектов, и все это в конечном итоге сводится к природе проекта. Серверный стек не будет выходить из окна после того, как ваши рабочие процессы начнут становиться сложными или вы предложите UX, в отличие от простых приложений, ориентированных на данные. Когда ваш проект включает в себя большие UX backbonejs, вы можете получить там. Даунсайд - это то, что нет четко определенных централизованных рекомендаций для вас, вам придется пройти через ад блогов, чтобы все было сделано. Для обычных приложений вы можете придерживаться KO. Btw есть плагины, которые могут издеваться над KO для backbonejs. Я имею в виду bacjbone.modelbinder снова вам нужно интегрироваться для себя. Cuz MS вообще не будет беспокоиться.