Есть ли причина, по которой я бы использовал Knockout MVC вместо Knockout JS?

Knockout MVC — незаконнорожденный ребенок WebForms. Он направляет все методы модели представления через действия контроллера, а это означает, что все, что происходит, должно возвращаться на сервер и обратно. Я не могу понять, почему кто-то может взять такую ​​​​инфраструктуру, как нокаут, которая предназначена для MVVM на стороне КЛИЕНТА, и заставить ее вызывать сервер для каждой функции.

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

Использование Knockout MVC означает отказ от всех преимуществ производительности клиентского кода в пользу отсутствия необходимости писать javascript. Тот же самый компромисс сделали WebForms. Это не очень хорошо. Это антипаттерн.

Если Knockout MVC умрет завтра, Интернет станет лучше.

Я только что наткнулся на этот вопрос, на который есть довольно негативные ответы. Я собираюсь быстро добавить свои пять центов.

Я только начал использовать KnockoutJS. Поскольку я создаю приложения ASP.NET MVC, мне показалось логичным использовать что-то вроде Knockout MVC. По большей части это кажется отличной идеей. Я не хочу тратить время на написание javascript и <!-- ko --> комментариев на своих страницах, если я могу сделать то же самое, используя функции .Net, которые я знаю и люблю.

Сказав это... да, на данный момент у KMVC есть ограничения. Отправка всей модели обратно на сервер — большая проблема. Итак, что я сделал, так это запустил свой собственный форк нокаута-mvc. Изменения были обязательно поспешными в данный момент. Но теперь у меня есть возможность:

• создавать подконтексты (с совершенно разными моделями или компонентами модели представления)
• передавать выбранные части модели обратно при вызове сервера
• ожидать от звонка другую модель, чем та, что была отправлена
• пожарные события вокруг вызовов ajax
• поддержка большего количества типов ввода html5
• передавать токены защиты от подделки на сервер через заголовки (для вызовов ajax)
• наверное больше я забыл

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

я определенно думаю

Если Knockout MVC умрет завтра, Интернет станет лучше.

был немного суров.

Изменить:

Я просматривал комментарии и снова посмотрел на исходный вопрос. Сделав это, я думаю, что к моему ответу следует добавить немного больше:

Во-первых, первоначальный вопрос был следующим: Есть ли причина, по которой я буду использовать Knockout MVC вместо Knockout JS? Чтобы ответить/уточнить (может быть, я просто придирчив), что: Knockout MVC — это фреймворк, предназначенный для проще интегрировать KnockoutJS с вашим приложением ASP.NET MVC. В основном это достигается за счет использования знакомых строго типизированных конструкций для создания тегов KnockoutJS. Это не замена KnockoutJS. Обязательно используйте KnockoutJS. На самом деле вопрос заключается в том, следует ли использовать Knockout MVC также.

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

Использование Knockout MVC не мешает использовать KnockoutJS в полной мере. Использование Knockout MVC не мешает писать дополнительный код javascript для обработки любого количества клиентских функций. Тот факт, что Knockout MVC предоставляет вам короткий путь для генерации обратных вызовов ajax на сервер, не означает, что вы должны их использовать. Хотя, если ваше приложение когда-либо сохраняет данные, в какой-то момент ему придется позвонить домой.

Есть причины для создания серверной части приложения с использованием ASP.NET MVC по сравнению с использованием Apache только для обслуживания статических файлов HTML и сценариев. Knockout MVC позволяет вам продолжать пользоваться теми же преимуществами при интеграции KnockoutJS.

Я нахожу ответ Тирсиуса слишком отрицательным. Knockout MVC все еще находится на ранней стадии разработки, но, насколько я вижу, он имеет некоторые преимущества и менее загружен сервером, чем, например, Webforms. Зависимости видимости полностью обрабатываются клиентом, только при использовании функций вызов выполняется на сервер. При работе со сложными структурами данных иногда в любом случае требуется пройти через сервер, поэтому Knockout MVC может быть хорошим способом сэкономить на написании большого количества Ajax-обработки самостоятельно.

Это правда, что он всегда отправляет всю модель туда и обратно, что дает некоторые накладные расходы, в отличие от создания ее самостоятельно. Но полностью списывать со счетов я бы не стал. Особенно, когда он получает надлежащую обработку на стороне клиента для сложных проверок в будущем.

Я наткнулся на этот пост после небольшого поиска о нокауте mvc. Хотя я согласен с пустой тратой пропускной способности сети, меня очень соблазнила эта строка кода:

@{
  var ko = Html.CreateKnockoutContext();
 }

Это аккуратный и чистый способ создания модели нокаута. Кто-нибудь использовал нокаут MVC только для этой функции и без переноса всей логики на сервер?

Прелесть Knockout.js заключается в том, что вы можете обслуживать свое приложение, просто передавая JSON туда и обратно с сервера, без необходимости отправлять все представление, которое сервер должен был разбить на фрагменты для генерации HTML.

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

Мое предложение состояло бы в том, чтобы использовать Knockout.js для привязки, чтобы привязка происходила на клиенте, а не на сервере, если это цель, к которой вы стремитесь. Если вы хотите, чтобы ваше представление было привязано к данным на сервере, используйте razor.

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

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

Разработчик может перевести всю необходимую бизнес-логику в методы java-скрипта внутри модели представления Knockout.js. Но таким образом дизайн нарушает правило централизованного управления бизнес-логикой.

Обслуживание станет кошмаром для такого дизайна.

Резюме: выбор фреймворка действительно зависит от требований бизнеса. Иногда производительность не стоит на первом месте.

Я также вижу много хороших вариантов использования библиотеки Knockout MVC. Я с трудом смог интегрировать KnockoutJS в наше веб-приложение MVC именно по причинам, которые указал, например, @ChinaHelloWorld. Вот несколько случаев, когда я нахожу это чрезвычайно полезным.

1. Строго типизированные привязки

Мне понравились хорошие HTML-хелперы со строгой типизацией, которые стали совершенно бесполезными и беспорядочными, когда дело дошло до настройки KnockoutJS. Лучшее, что я мог сделать, это вручную прикрепить свои атрибуты привязки с дополнительным параметром вспомогательных методов, но мне снова пришлось использовать магические строки. Мне нравятся помощники, предоставляемые Knockout MVC для создания входных данных и других элементов со строго типизированными привязками на основе выражений C#. Однако здесь я хотел бы упомянуть, что мне не хватает атрибута имени сгенерированных полей, поэтому мне нужно было немного его подправить.

2. Синтаксис привязки со строгой типизацией (вид)

При использовании чистых привязок строк всегда есть большая вероятность опечатки или точного знания правильного формата привязки, которую вы хотите применить. С плавным API Knockout MVC и VS IntelliSense очень легко применять правильные привязки.

3. (Почти) Автоматическое преобразование вычисляемых свойств C# в вычисляемые привязки

Просто с применением небольшого атрибута [Computed] Knockout MVC может сгенерировать соответствующее выражение привязки в правильном синтаксисе KnockoutJS. Это тоже очень полезно, я думаю.

4. Нет дублирования кода модели представления

Классическим способом мне нужно было иметь класс модели представления в коде C#, а затем (почти) такой же код модели представления в JS (с наблюдаемыми). Что ж, ЭТО меня расстроило, и я был очень счастлив, когда увидел технику, используемую в Knockout MVC. Однако мне нужно было немного настроить его, чтобы иметь возможность использовать его с действительно сложными моделями представления (вложенными моделями представления, коллекциями и т. д.) и иметь возможность расширять отображаемые модели представления Knockout, например, с помощью любого необходимого пользовательского метода JS или вычисляемого наблюдаемого. .

Итак, вот как минимум четыре очень хороших момента. И насчет обхода модели представления: никто не говорил, что кому-то из нас нужно использовать серверный механизм обработки Knockout MVC. Я бы тоже не стал использовать это, только если есть какая-то сложная бизнес-логика, которую действительно нужно обрабатывать на сервере. Но в большинстве случаев Knockout MVC предназначен только для упрощения процесса привязки и настройки MVC Views и KnockoutJS. Так что я не совсем понимаю плохие мнения выше. Я думаю, что те, кто писал эти мнения, не потрудились изучить хотя бы базовые концепции Knockout MVC. Вы определенно НЕ должны использовать Knockout MVC вместо KnockoutJS, кроме KnockoutJS. Понимание Javascript и хотя бы основ KnockoutJS по-прежнему является обязательным в любом случае.

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

В шаблоне .Net MVC модель представления уже четко обозначена в каждом представлении/частичном представлении с помощью тега «@model yourmodel», что может помочь разработчику понять, что будет делать в этом представлении.

При использовании шаблона Knockout.js MVVM вы, возможно, не увидите никакой модели представления .Net, кроме тегов, таких как «привязка данных» в представлениях. Это сделало бы представление и контроллер несвязанными и затруднило бы отслеживание логики, особенно для нового разработчика в команде.

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

Поскольку KnockoutMVC заставляет дизайн по-прежнему придерживаться модели представления на стороне сервера, которую легко отслеживать и поддерживать, поскольку это код C#.

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

Немного пожертвуйте производительностью, но упростите ее. Ключевым моментом должна быть согласованность на стороне клиента и на стороне сервера. Javascript — большая проблема с обслуживанием.

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

У вас все еще есть производительность, если вы не используете функции, созданные komvc. Как сказал Найджел, первоначальная генерация страницы все равно должна быть сгенерирована сервером. Вы всегда можете добавить пользовательские сценарии и создать функции на стороне клиента, которым не нужно будет возвращаться на сервер. Это инструмент, который дает разработчику немного производительности. Сравнение с веб-формами по производительности явно преувеличено. Ребята, это один из инструментов, который точно поможет вам уложиться в срок.

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

Оставляя в стороне точку зрения безопасности, я лично считаю, что нокаут js — это способ усложнить asp.net MVC, и его следует использовать как есть (нокаут js) с чистыми приложениями RESTful, такими как asp.net webapi.

Knockout MVC — это мощное расширение для ASP .NET MVC, которое позволяет вам реализовать функциональность клиента веб-сайта непосредственно в вашем проекте .NET с помощью удобных для разработчиков API Fluent API без Javascript и удаления большого количества дублированного и повторяющегося кода.
Knockout MVC — это так же, как кодирование бритвы ASP .NET MVC, и вы получаете функциональность клиента без каких-либо дополнительных хлопот.
Вам не нужно кодировать модель представления и строки кода привязки.
Я использую koMVC на большинстве моих веб-сайтов, а также сокращение времени разработки, простота обслуживания и минимальная кривая обучения — огромная отдача.
Я предлагаю вам проверить их веб-сайт и попробовать несколько живых примеров. http://knockoutmvc.com
Вам не потребуется много времени, чтобы влюбиться в него.

MVC — это архитектурный шаблон, который разделен на три компонента: модель, представление и контроллер.

KnockoutJS лучше всего работает с архитектурой MVC, поскольку привязка данных фреймворка требует использования контроллера. Существуют фреймворки, такие как AngularJS, которые больше ориентированы на внешний интерфейс и поэтому лучше работают с архитектурным шаблоном MVVM (модель, представление, модель представления). Их функции привязки данных также не требуют использования контроллера, который уменьшает объем привязки.