Есть ли причина, по которой я бы использовал Knockout MVC вместо Knockout JS?
Другой пользователь предложил Knockout MVC решить некоторые проблемы с публикацией AJAX. Я прочитал немного об этом, и я вижу, что это обертка вокруг Knockout JS. Поэтому мне интересно, каковы реальные различия между этими двумя? Должен ли я беспокоиться о Knockout JS, поскольку существует Knockout MVC? Когда бы я использовал один поверх другого?
12 ответов
Knockout MVC - ублюдочный ребенок WebForms. Он направляет все методы viewmodel через действия контроллера, то есть все, что происходит, должно возвращаться на сервер и обратно. Я не могу понять, почему кто-то взял бы фреймворк, такой как knockout, который должен быть MVDM на стороне клиента, и заставил его вызывать сервер для каждой функции.
Кроме того, выполнение этих методов на сервере означает, что вся view-модель должна передаваться на сервер и обратно клиенту для каждого вызова функции. Это невероятно расточительно.
Использование Knockout MVC означает пожертвование всеми преимуществами кода на стороне клиента в пользу отсутствия необходимости написания javascript. Тот же компромисс, сделанный WebForms. Это не очень хорошо. Это антипаттерн.
Если Knockout MVC умрет завтра, сеть станет лучшим местом.
Я только что наткнулся на этот вопрос, на который есть довольно негативные ответы. Я собираюсь быстро добавить свои два цента.
Я только начал использовать KnockoutJS. Поскольку я создаю приложения ASP.NET MVC, мне кажется логичным использовать что-то вроде Knockout MVC. По большей части это кажется отличной идеей. Я не хочу тратить время на написание JavaScript и <!-- ko --> комментарии через мои страницы, если я могу сделать то же самое, используя.Net функциональность, которую я знаю и люблю.
Сказав это... да, на данный момент существуют ограничения для KMVC. Отправка всей модели обратно на сервер является большой. Итак, что я сделал, так это запустил свой собственный форк knockout-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 для выполнения привязки, чтобы привязка выполнялась на клиенте, а не на сервере, если это ваша цель. Если вы хотите, чтобы ваше представление было привязано к данным на сервере, используйте бритву.
Более того, knockout.js, безусловно, очень хорош для отображения / удаления / вставки / обновления данных на стороне клиента, а также для расчета данных на стороне клиента. Если реальная бизнес-логика так проста, мы должны применить knockout.js напрямую.
Правда в том, что бизнес-логика не всегда так проста. Например, когда клиент вставляет новую запись в представление, системе, возможно, потребуется проверить аутентификацию пользователя, установить значения по умолчанию для нового созданного объекта на основе некоторой бизнес-логики или формулы и т. Д. Все это в любом случае должно идти на сторону сервера и проверять логика на основе данных базы данных.
Разработчик может перевести всю необходимую бизнес-логику в методы java-скрипта внутри модели представления knockout.js. Но при этом дизайн нарушает правило централизованной обработки бизнес-логики.
Сопровождение станет кошмаром для такого дизайна.
Резюме, выбор рамок действительно зависит от требований бизнеса. Иногда производительность - это не первое соображение.
Я также вижу много хороших примеров использования библиотеки Knockout MVC. Я едва мог интегрировать KnockoutJS в наше веб-приложение MVC, именно по причинам, указанным, например, @ChinaHelloWorld. Вот несколько случаев, когда я нахожу это чрезвычайно полезным.
- Строго набранные привязки
Мне понравились хорошие строго типизированные методы HTML-помощников, которые стали совершенно бесполезными и грязными, когда дело дошло до настройки KnockoutJS. Лучшее, что я мог сделать, - это вручную прикрепить свои атрибуты привязки с дополнительным параметром вспомогательных методов, но мне снова пришлось использовать магические строки. Мне нравятся помощники, предоставляемые Knockout MVC для создания входных данных и других элементов со строго типизированными привязками на основе выражений C#. Однако здесь я хотел бы упомянуть, что мне не хватает атрибута name сгенерированных полей, поэтому мне пришлось немного его подправить.
- Строго типизированный синтаксис привязки (вид)
При использовании чистых привязок к строке всегда есть большая вероятность ошибочного написания или неправильного определения правильного формата привязки, который вы хотите применить. Благодаря свободному API Knockout MVC и VS IntelliSense действительно легко применять правильные привязки.
- (Почти) Автоматическое преобразование из вычисленных свойств C# в вычисленные привязки
Просто с помощью небольшого атрибута [Computed] Knockout MVC может генерировать соответствующее выражение привязки в правильном синтаксисе KnockoutJS. Это тоже очень полезно, я думаю.
- Нет дублирования кода модели представления
Классическим способом мне нужно было иметь класс viewmodel в коде C#, а затем (почти) тот же код viewmodel в JS (с наблюдаемыми). Что ж, это расстраивало меня, и я очень обрадовался, когда увидел технику, используемую в Knockout MVC. Однако мне нужно было немного его настроить, чтобы иметь возможность использовать его с действительно сложными моделями представления (вложенными моделями представления, коллекциями и т. Д.), А также иметь возможность расширять сопоставленные модели представления Knockout, например, любым необходимым пользовательским методом JS или вычисляемым наблюдаемым,
Итак, вот как минимум четыре очень хороших момента. И про обходы модели представления: никто не сказал, что кому-либо из нас нужно использовать механизм обработки на стороне сервера Knockout MVC. Я бы тоже не использовал это, только если есть какая-то сложная бизнес-логика, которая действительно должна быть обработана на сервере. Но в большинстве случаев Knockout MVC просто для упрощения процесса привязки и настройки MVC Views и KnockoutJS. Так что я не совсем понимаю плохое мнение выше. Я думаю, кто написал эти мнения, не приложил усилий, чтобы изучить хотя бы основные концепции Knockout MVC. Yout определенно НЕ должен использовать Knockout MVC вместо KnockoutJS, но кроме KnockoutJS. Понимание Javascript и, по крайней мере, основ KnockoutJS по-прежнему обязательно в любом случае.
Я хотел бы, чтобы автор продолжил разработку Knockout MVC, потому что помимо этих хороших моментов, есть некоторые функции и усовершенствования, которые действительно сделали бы его еще более мощным.
В шаблоне.Net MVC модель представления, уже отмеченная в каждом представлении / частичном представлении, четко помечается тегом "@model yourmodel", который может помочь разработчику понять, что будет делать в этом представлении.
При использовании шаблона MVVM knockout.js вы, возможно, не увидите модель представления.Net, кроме тегов типа "привязка данных" в представлениях. Это сделало бы представление и контроллер несвязанными и затруднило бы отслеживание логики специально для нового разработчика в команде.
Я полагаю, что knockoutMVC может решить такие проблемы и сохранить множество javascript-кодов, которые затруднят поддержку и понимание системы.
Поскольку knockoutMVC заставляет дизайн по-прежнему придерживаться применения серверной модели представления, которую легко отслеживать и поддерживать, поскольку это код C#.
Для бизнес-проекта менеджер всегда должен сосредоточиться на простоте разработки, простоте обслуживания, простоте обновления, простоте понимания и быстрой доставке, чтобы заработать деньги.
Немного пожертвуйте производительностью, но упростите ее, ключевым моментом должна быть согласованность на стороне клиента и на стороне сервера. Javascript - большая проблема обслуживания.
Действительно ли важно возвращать всю модель представления обратно на серверную часть? Если это так, мы можем разделить большую модель на несколько маленьких моделей.
У вас все еще есть производительность, если вы не используете функции, сгенерированные komvc. Как сказал Найджел, первоначальное генерирование страницы все равно должно быть сгенерировано сервером. Вы всегда можете добавить пользовательские сценарии и создать функции на стороне клиента, которым не нужно возвращаться на сервер. Это инструмент, который дает разработчику немного производительности. Сравнение с веб-формами по производительности несомненно преувеличено. Люди, это один инструмент, который, безусловно, поможет вам уложиться в срок.
Knockout MVC - это мощное расширение для ASP .NET MVC, которое позволяет вам реализовать функциональность клиента веб-сайта непосредственно в вашем.NET-проекте, используя дружественные для разработчика fluentAPI без Javascript и удаляя много дублирующегося и повторяющегося кода.
нокаут MVC аналогичен кодированию бритвы ASP .NET MVC, и вы получаете функциональность клиента без лишних хлопот.
Вам не придется кодировать модель представления и строки связующего кода.
Я использую koMVC на большинстве своих веб-сайтов, и сокращение времени разработки, простота обслуживания и минимальная кривая обучения являются огромным преимуществом.
Я предлагаю вам проверить их веб-сайт и попробовать некоторые живые примеры. http://knockoutmvc.com/
Вам не понадобится много времени, чтобы влюбиться в него.
Я добавлю свои 2 цента в пользу knockoutjs, хотя писать немного сложнее, чем MVC, но вы получаете огромную выгоду, когда дело доходит до повторного использования. Код клиента может гармонично работать и с другими технологиями.
Не говоря уже о безопасности, я лично считаю, что нокаут js является способом усложнения MVC asp.net, и его следует использовать как есть (нокаут js) с чистыми приложениями RESTful, такими как asp.net webapi.
MVC - это шаблон архитектуры, который разделен на три компонента: модель, представление и контроллер.
KnockoutJS лучше всего работает с архитектурой MVC, поскольку привязка данных платформы требует использования контроллера. Существуют фреймворки, такие как AngularJS, которые больше ориентированы на внешний интерфейс, и поэтому они лучше работают с шаблоном архитектуры MVVM (модель, представление, модель представления). Их функции привязки данных также не требуют использования контроллера, который уменьшает область привязки.