Учитывая самые популярные шаблоны клиентской модели MVC/MVVM (например, Knockout.js, Angular.js, Ember.js и другие), у меня есть одно большое сомнение:
Рассматривая также избыточность моделирования с обеих сторон, каковы преимущества и недостатки использования этих шаблонов на стороне клиента с шаблонами на стороне сервера MVC?
Я боролся с тем, как ответить на этот вопрос... надеюсь, это помогает, даже если это происходит вокруг.
В то время как некоторые из плюсов и минусов уже заявлены, я думаю, что наилучшее изложение находится в этом ответе.
Для меня самым большим преимуществом использования клиентской логики является богатый пользовательский интерфейс.
Но ключевой частью вашего вопроса является "модельная избыточность" (я бы назвал ее дублированной логикой или, по крайней мере, имеющей потенциал для дублированной логики). На мой взгляд, это проблема, которая может существовать независимо от плюсов и минусов в предыдущей ссылке.
Итак, прежде всего, я думаю, что решение о том, следует ли использовать клиентскую структуру, должно быть основано на хорошо задокументированных плюсах и минусах. Как только это решение будет принято, связанные проблемы могут быть решены.
Предположим, что вы используете какую-то структуру/платформу на стороне сервера, а также платформу на стороне клиента, чтобы обеспечить немного интерактивности пользовательского интерфейса. Теперь возникает проблема с тем, где поставить логику модели: на клиент, сервер или на оба.
Один из способов решения проблемы - определить вашу модельную логику только на сервере или. Тогда у вас нет дублирования кода, но это влияет на некоторые из плюсов/минусов более высокого уровня.
Например, если ваша модельная логика на 100% -ной стороне сервера, вы теряете часть интерактивной части пользовательского интерфейса. Или вы постоянно бросаете модель на/с сервера, у которой будет несколько минусов.
Если ваша модельная логика составляет 100% на стороне клиента, вы можете столкнуться с проблемами производительности, в зависимости от размера вашего представления/модели. Это одна из причин, по которой Twitter переходит к серверной модели обработки.
Тогда есть "оба"... наличие модели логики существует как на клиенте, так и на сервере. Я думаю, что это лучшее решение, , если никакая логика не дублируется.
Например, на странице корзины покупок вы можете пересчитать стоимость заказа в зависимости от цены продукта и изменяемого пользователем поля количества. Я думаю, что эта логика должна существовать только на клиенте. Другие свойства модели, которые не меняются после загрузки, вероятно, хорошо размещены на сервере.
Здесь много серой зоны... Я изо всех сил пытаюсь положить все яйца в одну корзину. Например, выбирая инфраструктуру на стороне клиента, создавая много логики на стороне клиента, а затем [гипотетически] сталкиваетесь с проблемами производительности, поддержки браузера или чего-то в этом роде. Теперь вы можете настроить страницу или две для производительности (например, переместите ее на серверную, a la Twitter). Но я думаю, что умение о том, как вы структурируете свой код, поможет смягчить эту проблему. Если ваш код поддерживается и чист, перемещение логики от клиента к серверу не составит труда.
Преимущество заключается в том, что шаблоны клиентской стороны применимы на клиенте, где сервер не имеет прямого доступа. Если вы создаете богатый интерактивный HTML-интерфейс, используйте MVVM на стороне клиента. Сервер MVC на стороне сервера может по-прежнему быть релевантным в этом случае для доставки соответствующего контента клиенту. Например, ASP.NET WebAPI является основой для создания HTTP API, которая имеет аналогичную архитектуру контроллера для структуры ASP.NET MVC. API, реализованный в этой структуре, может быть вызван кодом на стороне клиента, в результате чего MVC на стороне сервера и MVVM на стороне клиента. Обычно, при использовании стороны сервера MVC и клиентской стороне MVVM, обязанности соответствующих сторон сильно различаются и, следовательно, нет избыточности.
Тот факт, что вы включаете MVVM-модель в уже реализованную MVC-инфраструктуру, тоже замечательно, мы недавно добавили нокаут на некоторые новые страницы проекта, чтобы они соответствовали уже устаревшей инфраструктуре MVC (старые страницы, а не сама инфраструктура),
Я думаю, что MVVM фантастичен, поскольку в приведенном выше ответе говорится, что он обеспечивает исключительный пользовательский интерфейс с чрезвычайно быстрым временем отклика, вы можете скрыть свои проверки на заднем плане, не замедляя их и интуитивно понятный.
Боль в том, что очень тяжело unit test, и вы можете получить некоторые чрезвычайно большие файлы javascript, а также дополнительное кодирование, которое мы должны были сделать, поскольку наши прежние системы, все еще работающие на IE6, смешны.
Но MVVM и MVC не обязательно должны использоваться исключительно там, мы используем оба. Но наличие трех уровней проверки - это то, что все еще меня беспокоит.
Серьезно. Использование переноса интерфейсной логики в браузере может повысить вашу разработку приложений, поэтому вы держите более строгую обработку данных, инкапсулированную на серверной стороне.
Это в основном расслоение. Два слоя, один выше говорит с одним ниже и наоборот:
[client] <--> [server]
Обычно вы меняете объекты значений в формате облегченного сериализации, например Json между ними.
Это может довольно хорошо отобразить то, что пользователи ожидают в полезной структуре, в то время как объекты домена на стороне сервера не могут быть такими подробными.
Однако реальная власть будет, если серверная сторона не написана в javascript в какой-то определенной точке, потому что я думаю, что вы не можете создавать там хорошо доменные объекты. Рассмотрим Scala (или что-то подобное выразительное), если вы столкнулись с этой проблемой.
Спустя десять месяцев после этого вопроса я использовал оба шаблона внутри одного и того же приложения.
Единственная проблема заключалась в необходимости сопоставления моделей дважды.
MVC (веб-API ASP.NET MVC 4)
Самым важным ресурсом были маршруты.
MVVM (Knockout.js)
В целом, комбинация MVC с MVVM была очень полезна, но для этого нужны были большой опыт и знания. Также требуется терпение, потому что вам нужно подумать об ответственности каждого уровня приложения.