Имеет ли смысл использовать модели просмотра KnockoutJS в сочетании с ASP.NET MVC3 или 4? Потому что это не очень СУХОЙ, не так ли? Мне приходится писать модели для EF, Viewmodels для MVC Views и Viewmodels для нокаута... и я теряю много магии. Автоматическая проверка на стороне клиента, например.
Имеет ли смысл использовать MVC вообще, если вы придерживаетесь шаблона MVVM?
Это может быть непопулярный ответ, но я не использую 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, как и вы.
С Отображение нокаута, вы можете автоматически генерировать модель просмотра KO из модели просмотра MVC.
Это правильный шаблон: ваши модели представляют собой необработанные сущности, ваши данные. Ваши взгляды - это пользовательский интерфейс. И ваши модели просмотра - это ваши модели, адаптированные к этому конкретному виду.
Мы используем отображение нокаута для генерации моделей представления KO.
У нас есть бизнес-уровень в отдельном проекте, который выполняет CRUD, отчетность, кеширование и некоторую дополнительную "бизнес-логику". Мы не собираемся использовать EF или что-то подобное. В настоящее время мы определили классы С# как модели MVC, и наши контроллеры вызывают бизнес-уровень для построения моделей, которые определены в обычном месте в нашем приложении MVC. Эти модели С# сериализуются как JSON для использования на наших страницах.
Так как все, что мы делаем в браузере, это С#/JSON, основанный на использовании нокаута, мы не используем MVC-модели в традиционном способе MVC - все отправляется как JSON и сериализуется на С#, поэтому мы не используем привязку модели MVC, проверка и т.д. Мы рассматриваем возможность перемещения этих моделей на наш бизнес-уровень, чтобы их можно было тестировать независимо от веб-приложения.
Se у нас останется приложение MVC с контроллерами и представлениями, но никакие модели - контроллеры не получат модели, которые определены в бизнес-слое. Мы нервничаем из-за отклонения от нормальной структуры MVC, но клиент KO/javascript принципиально отличается от клиента на основе DOM, изначально построенного MVC.
Это звучит как жизнеспособный способ?
Сейчас я работаю над проектом, который смешивает MVC3 и нокауты, и я должен сказать вам - это беспорядок... ИМО это бессмыслица, чтобы заставить некоторые модели просто обновляться с тенденцией.
Это старая тема, но теперь в 2014 году (к сожалению) я все еще чувствую, что этот вопрос имеет огромное значение.
В настоящее время я работаю над проектом, который смешивает MVC4 с knockoutjs. У меня были некоторые трудности, чтобы найти, какая часть должна быть обработана с какой стороны. Кроме того, нам нужна архитектура типа "SPA-иш", где каждый модуль имеет свою собственную страницу, но внутри этого модуля есть только взаимодействие AJAX. Также столкнулись с некоторыми тяжелыми сценариями проверки и необходимы для обеспечения дружественных URL-адресов пользователей (и SEO) внутри каждого модуля. Я закончил с концепцией, которая, кажется, работает хорошо:
Основные роли MVC и .NET:
Основные роли на стороне клиента:
Я надеюсь, что это может помочь любому, кто чувствует себя потерянным в мире модных технологий. Пожалуйста, если кто-нибудь подумает об этом, не стесняйтесь публиковать какие-либо вопросы или предложения в комментариях.