ASP.NET MVC с Knockout и Web API: имеет ли это смысл?

Question

имеет ли смысл использовать KnockoutJS Viewmodels в сочетании с ASP.NET MVC3 или 4? Потому что это не очень сухо, не так ли? Я должен написать модели для EF, Viewmodels для MVC Views и Viewmodels для Knockout ... и я теряю много магии. Автоматическая проверка на стороне клиента, например.

Имеет ли смысл вообще использовать MVC, если придерживаться модели MVVM?

Answer 1

С помощью Knockout Mapping вы можете автоматически генерировать модель вида KO из модели вида MVC.

Это правильная модель: ваши модели являются необработанными объектами, ваши данные. Ваши взгляды - это пользовательский интерфейс. А ваши модели представления - это ваши модели, адаптированные к этому конкретному виду.

Answer 2

Это может быть непопулярный ответ, но я не использую ko.mapping для перевода моих C # POCO в JS viewmodels. На самом деле две причины.

Первое - это отсутствие контроля. ko.mapping превратит все в наблюдаемое, если вы позволите. Это может привести к большим накладным расходам для полей, которые просто не должны быть наблюдаемыми.

Вторая причина связана с расширяемостью. Конечно, ko.mapping может перевести мой C # POCOS в объекты JS с наблюдаемыми свойствами. Это нормально до тех пор, пока вам не понадобится метод JS, который в какой-то момент вы всегда будете иметь.

В предыдущем проекте я фактически добавлял дополнительные методы к объектам ko.mapped программным способом. В этот момент я спросил, действительно ли ko.mapping создает больше проблем, чем решает.

Я принимаю к сведению ваши проблемы с СУХОЙ, но в любом случае у меня есть разные доменные версии моих POCO. Например, объект MyProject.Users.User, обслуживаемый UserController, может сильно отличаться от MyProject.Articles.User. Пользователь в пространстве имен Users может содержать множество вещей, связанных с администрированием пользователей. Объект User в пространстве имен Articles может быть простым поиском, указывающим на автора статьи. Я не рассматриваю этот подход как нарушение принципа СУХОЙ; скорее средство взглянуть на одну и ту же концепцию двумя разными способами.

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

Так же и с моделями представления Javascript. Они не C # POCO. Это конкретный подход к концепции, подходящей для конкретной цели; хранение и работа с данными на стороне клиента. В то время как ko.mapping первоначально даст вам то, что кажется повышением производительности, я думаю, что лучше создавать вручную конкретные модели представлений, разработанные для клиента.

Кстати, я использую ту же стратегию MVC3 / KnockoutJS, что и вы.

Answer 3

Мы используем выбивающее отображение для хорошей генерации моделей представления KO.

У нас есть бизнес-уровень в отдельном проекте, который включает CRUD, отчетность, кэширование и некоторую дополнительную «бизнес-логику».Мы не собираемся использовать EF или что-то подобное.В настоящее время мы определили классы c # как модели MVC, и наши контроллеры вызывают бизнес-уровень для создания моделей, которые обычно определяются в нашем приложении MVC.Эти модели C # сериализуются как JSON для использования на наших страницах.

Поскольку все, что мы делаем в браузере, основано на c # / JSON с использованием нокаута, мы не используем модели MVC традиционным способом MVC - все публикуется как JSON и сериализуется в c #, поэтому мы не используемПривязка моделей MVC, валидация и т. Д. Мы рассматриваем возможность переноса этих моделей на наш бизнес-уровень, чтобы их можно было протестировать независимо от веб-приложения.

Итак, у нас останется приложение MVC с контроллерами ипредставления, но не модели - контроллеры получат модели, определенные на бизнес-уровне.Мы нервничаем по поводу отхода от нормальной структуры MVC, но клиент на основе KO / javascript в корне отличается от клиента на основе DOM, вокруг которого изначально был создан MVC.

Похоже ли это на жизнеспособный путь?

Answer 4

Это старая тема, но сейчас, в 2014 году (к сожалению), я все еще чувствую, что этот вопрос имеет огромное значение.

В настоящее время я работаю над проектом, который смешивает MVC4 с knockoutjs.У меня были некоторые трудности, чтобы найти, какая часть должна быть обработана с какой стороны.Также нам была нужна архитектура типа «SPA-ish», где у каждого модуля есть своя страница, но внутри этого модуля есть только взаимодействие AJAX.Также столкнулся с некоторыми тяжелыми сценариями проверки и должен был предоставить дружественные пользователю (и SEO) URL-адреса внутри каждого модуля.Я получил следующую концепцию, которая, кажется, работает хорошо:

Основные роли на стороне MVC и .NET:

• Обработка аутентификации и другие меры безопасности.
• Реализация интерфейса веб-API для вызовов на стороне клиента (настройка моделей представления, извлечение и сопоставление данных из домена и т. Д.)
• Генерациявычеркнуть модели из моих (ранее существовавших) моделей C # с шаблонами T4 , включая расширения расширения валидации из атрибутов валидации .NET.(Это было вдохновлено этой статьей ).Сгенерированные модели представления легко расширяемы, и генерация может быть выполнена с помощью нескольких пользовательских или встроенных атрибутов, подобных аннотациям данных (таких как DefaultValue, Browsable, DataType, DisplayFormat и т. Д.).Таким образом, СУХОЙ не нарушается (слишком много).
• Предоставление строго типизированных , но независимых от данных шаблонов частичного представления для каждого подмодуля (каждая нокаутируемая модель представления).Поскольку имена свойств в моделях представления C # такие же, как в моделях KO, я могу извлечь выгоду из строго типизированных помощников, специально написанных для привязок KO и т. Д.
• Предоставление основного вида для каждого модуля аналогичнопредыдущий пункт.
• Объединение и минимизация всех скриптов и таблиц стилей.

Основные роли на стороне клиента:

• Загрузка начального состояния всех видовых моделей, инкапсулированных в одну страницу модуля, с учетом всего URL с помощью простой реализации анализатора маршрутов.
• Обработка истории с history.js
• Привязка данных, взаимодействие с пользователем обработка.
• Отправка соответствующих частей моделей представления на сервер и обработка возвращенных данных (обычно обновление некоторой модели представления с помощьюэто).

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

Answer 5

Я сейчас работаю над проектом, который смешивает MVC3 и нокауты, и я должен сказать вам - это беспорядок ... ИМО - это бессмыслица заставлять некоторые паттерны просто соответствовать тренду.