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

Ответ 1

Нокаутом MVC является дочерний bastard WebForms. Он направляет все методы viewmodel с помощью действий контроллера, что означает, что все, что происходит, должно отскакивать от сервера и обратно. Я не могу понять, почему кто-то возьмет фреймворк, такой как нокаут, который должен быть CLIENT SIDE MVVM, и заставить его вызывать сервер для каждой функции.

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

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

Если Knockout MVC умирает завтра, сеть будет лучше.

Ответ 2

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

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

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

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

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

Я определенно думаю, что

Если Knockout MVC умирает завтра, сеть будет лучше.

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

Edit:

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

Во-первых, исходный вопрос был Есть ли причина, по которой я бы использовал 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 и script файлов. Нокаут MVC позволяет вам продолжать использовать те же преимущества, чтобы помочь с интеграцией KnockoutJS.

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ведение станет кошмаром для такого дизайна.

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

Ответ 7

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

• Сильно-типизированные привязки

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

2. Сильно синтаксис синтаксиса (вид)

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

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

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

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

В классическом виде мне нужно было иметь класс viewmodel в коде С#, а затем (почти) тот же код viewmodel в JS (с наблюдаемыми). Ну, это меня расстраивало, и я очень обрадовался, увидев технику, используемую в Knockout MVC. Тем не менее, мне нужно было немного настроить его для возможности использовать его с действительно сложными режимами просмотра (вложенными режимами просмотра, коллекциями и т.д.) И иметь возможность расширять отображаемые модели отображения Knockout, например, любым необходимым пользовательским JS-методом или вычисленным наблюдаемым.

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

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

Ответ 8

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

При использовании шаблона MVVM от knockout.js вы, возможно, не увидели бы какую-либо модель. Net, кроме таких, как "привязка данных" в представлениях. Это сделало бы просмотр и контроллер разомкнутыми и трудно отслеживать логику специально для нового разработчика в команде.

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

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

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

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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