ASP.Net MVC против HTML + KnockoutJS + WebAPI

Мне интересно, почему не просто статические HTML файлы в ASP.Net MVC 4 Web Project, которые используют jQuery + jQuery Templates + KnockoutJS, использующую REST (ASP.Net MVC 4 WEB API, размещенный на Azure и защищенный с помощью ACS). Веб-API может использовать Entity Framework и возвращать сериализованные объекты JSON, которые можно получить с помощью $.ajax() и связать с помощью KnockoutJS.

Что такое ASP.Net MVC (для веб-страниц), что добавляет ценность этой архитектуры?
Сверху, я могу думать:

  • Поддержка нескольких устройств (обнаружение устройств и замена шаблонов)
  • Проверка данных на стороне сервера (не уверен, что я также могу поместить проверки в WEB API?)
  • Я все еще могу переписать свои URL-адреса, даже если я использую статические html файлы (поскольку я использую ASP.Net MVC в любом случае).

Может кто-нибудь помочь мне понять это лучше? Спасибо заранее.

ОТВЕТЫ

Ответ 1

Отличный вопрос. Я уверен, что мой код MVC/Razor становится все меньше и меньше, когда я продвигаюсь с моим проектом Knockout, но я думаю, что у меня всегда будут некоторые аспекты представлений, которые я хочу определить на стороне сервера.

Фундаментальные контекстуальные вещи, например, как визуализировать входную/выведенную панель на странице макета, связанные с ролями решения относительно того, что должно быть доступно, и т.д. Я думаю, если бы вы были достаточно осторожны с вашей безопасностью и реализовали достаточный защитный код на сервер, когда кто-то на самом деле пытается что-то сделать, тогда вы можете достичь большей части этого в Нокауте, но вы, вероятно, в конечном итоге получите огромное количество раздумий, питающихся всеми возможными частями зрения.

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

Если ничего другого, вы можете захотеть ссылки и т.д. в своих представлениях индексироваться поисковыми системами. Если вы отпустите, скажем, свои "последние 10 продуктов" в JSON и сделайте их гиперссылками в шаблоне нокаута, вы проиграете это.

Ответ 2

Это действительно вопрос использования правильного инструмента для работы.

Из того, что я могу сказать после разработки с нокаутом, это реальная сила происходит от наблюдаемых и в реальном времени обновлений DOM. Это упрощает создание богатого интерфейса в клиентских приложениях и упрощает управление. Тем не менее, это еще более трудоемко и сложно реализовать, чем работа с прямыми страницами Razor. Таким образом, Knockout JS является преимуществом для определенных приложений, где множество пользовательских пользовательских интерфейсов, основанных на данных, должно происходить "аяксиально", но будет излишним для других.

Ответ 3

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

Используя синтаксис MVC Framework и Razor, вы все равно можете создавать динамически генерируемый контент, управляемый данными, без использования jQuery или AJAX. MVC предоставит вам четкое разделение проблем между вашей моделью и вашим представлением независимо от того, включен ли Javascript.

Ответ 4

Безопасность, вероятно, является преимуществом номер 1, которое я вижу. У вас все еще есть структура ASP.NET. Да, это правда, в ваших взглядах вы можете использовать синтаксис бритвы и иметь свою модель представления с помощью Knockout, а JSON.NET упрощает привязку данных. В конечном счете, в будущем, возможно, MVC не будет частью уравнения в будущем? (проверьте Meteor js тоже, его злой классный, и этот тип привязки динамической модели просто невозможен ни с чем другим, кроме javascript atm.)

Также, если вы хотите увидеть его в действии, я нашел хороший Codeproject с MVC и нокаутом. http://www.codeproject.com/Articles/424642/Customer-KnockoutJS-and-MVC-demo-using-JSON

Ответ 5

Здесь прочитайте это. Цитата:

Его больше не достаточно, чтобы создавать веб-приложения вокруг полноразмерных загрузок а затем "постепенно улучшают" их поведение более динамично. Создание приложений, которые бывают быстрыми, отзывчивыми и современными, требует от вас полностью переосмыслите свой подход.

Что касается вашего вопроса, что предлагает MVC, что добавляет ценность для MVVM-архитектуры? Преимуществом может быть использование пользовательского контента на различных устройствах, но вы можете сделать это в определенной степени с помощью запросов в формате CSS. Решение сводится к тому, сколько байтов вы хотите отправить с сервера на устройство.

Вы можете выполнять проверки на стороне сервера, не используя также MVC или WebAPI, и вам не нужно использовать ModelBinder или ModelState.IsValid для этого. Посмотрите на что-то вроде FluentValidation.NET, что позволяет выполнять очень сложные проверки ввода на сервере, даже на один уровень ниже уровня вашего Web/HTTP. Конечно, вы также хотели бы проверить на стороне клиента что-то вроде проверки jQuery.

Я согласен с другими ответами здесь, что некоторые элементы уровня безопасности на сервере (уровень действия контроллера или бритвы) немного легче и немного более "заслуживают доверия". Но никто больше не упоминал об испытании MVVM. Очень легко писать модульные тесты вокруг действий контроллера или другого кода на стороне сервера. Это не означает, что вы не можете тестировать приложения/интеграцию/UAT MVVM, просто для этого требуется больше усилий IMO.