Должны ли данные, которые можно легко вычислить на стороне клиента, помещаться во ViewModel?

Проблема

Скажем, я хочу отобразить некоторые значения на веб-сайте в соответствии с хорошими принципами MVC (а также с рекомендациями ASP.NET MVC, но проблема, скорее всего, не связана с конкретной инфраструктурой MVC), например:

А - число type A items,

Б - число type B items,

T - количество all items (общее количество),

A/T % - percentage of type A items,

B/T % - percentage of type B items,

Опции

Теперь я вижу несколько подходов к заполнению класса ViewModel для использования в представлении:

  1. Поместите all 6 values в ViewModel и просто отобразите их там, где это необходимо, без каких-либо вычислений на стороне клиента,

поскольку мы не принимаем расчеты на стороне клиента.

  1. Поместите только A, B в ViewModel, клиент вычислит общее количество (A+B) и процент (A/T % и B/T %),

поскольку мы хотим отправлять как можно меньше данных в ViewModel по сети.

  1. Поместите A, B, T в ViewModel, клиент вычислит процент (A/T % и B/T %),

поскольку мы считаем эти значения еще одним визуальным представлением уже полученных данных.

Вопрос

Какова наилучшая практика в отношении того, что должен содержать объект ViewModel?


asp.net-mvc asp.net-mvc-viewmodel
person jaccus    schedule 15.09.2014    source источник
comment
Я думаю, вы пытаетесь микро-оптимизировать свой проект. Возможные варианты: 1 - вычисление 3 простых операций на стороне клиента совсем не дорого; 2 — отправка 3 дополнительных значений совсем не затратна; 3 — смешивание 1 и 2 совсем не дорого. Надеюсь, вы понимаете, к чему я клоню.   -  person Andrei V    schedule 15.09.2014
comment
Рассматриваемая задача сведена к минимуму для простоты. Это могут быть огромные объемы данных для таких вещей, как статистические или финансовые диаграммы.   -  person jaccus    schedule 15.09.2014
comment
Тогда это действительно зависит от вашей системы. Если много пользователей выполняют запросы на вашем сервере, то имеет смысл пережить нагрузку на него. Слово легко в вашем заголовке вводит в заблуждение.   -  person Andrei V    schedule 15.09.2014
comment
@AndreiV прав. Это преждевременная и действительно чрезмерная оптимизация. Выполнение расчетов на стороне сервера или на стороне клиента обходится дешево. Если расчеты действительно настолько сложны, что стоят недешево, то это все равно на самом деле не имеет значения. Хотя обработка их на стороне сервера, где у вас, скорее всего, будет 8-ядерная машина плюс машина серверного класса, будет почти всегда лучше, чем полагаться на любую машину потребительского класса, которая, вероятно, будет у вашего конечного пользователя.   -  person Chris Pratt    schedule 15.09.2014

Ответы (2)


arrow_upward
1
arrow_downward

Преимущества серверной части:

  • Гарантирует правильность и согласованность значений для всех пользователей. Вы не полагаетесь на браузер для расчета. Особенно, если они финансовые и должны быть точными.
  • Гарантирует уровень производительности. Вы можете гарантировать, что все пользователи получат почти одинаковое время отклика, поскольку вы не полагаетесь на возможности компьютера пользователя для выполнения вычислений, а затем манипулируете DOM для их отображения - некоторые браузеры довольно медленны в этом. У пользователей может быть IE7 и очень медленный компьютер. Генерация значений на сервере означает, что вы также можете гарантировать совместимость с мобильными устройствами и устройствами с отключенным скриптом.

Преимущества клиентской стороны:

  • Может сэкономить трафик. Это будет зависеть от того, сколько вещей нужно рассчитать браузеру и не превышает ли сэкономленное пространство размер скрипта, необходимого для его работы.

Как видите, я склоняюсь к варианту на стороне сервера. Если вам нужно выполнить много вычислений, вы всегда можете кэшировать результаты, чтобы сократить требуемые ресурсы. Даже в этом случае вам необходимо сопоставить размер кеша с накладными расходами ЦП для вычислений.

person greg84    schedule 15.09.2014

arrow_upward
0
arrow_downward

Я полагаю, что вы говорите о тяжелом/SPA-приложении javascript.

Лично я бы выбрал вариант 2:

  • это уменьшит количество передаваемых данных
  • отправка минимально возможного набора данных позволяет клиенту легко вносить изменения в спецификацию
  • добавляет больше возможностей для динамического просмотра

Но есть некоторые минусы:

  • вы не можете легко протестировать эти вычисленные значения
  • потенциальная проблема с производительностью для медленных клиентов (старые мобильные телефоны)
person Marian Ban    schedule 15.09.2014