ASP.NET MVC с нокаутом и веб-API: это имеет смысл?

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

С Отображение нокаута, вы можете автоматически генерировать модель просмотра KO из модели просмотра MVC.

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

Ответ 3

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

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

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

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

Это звучит как жизнеспособный способ?

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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