Должны ли модели или виды генерировать строки для людей?

Question

Вот проблема, с которой я столкнулся в нескольких пользовательских приложениях: программа содержит компоненты для графического рендеринга данных (назовите их views ) и другие компоненты для управления этими данными (назовите их модель ).Некоторые из этих данных представлены в виде удобного для человека текста, часто пары ключевых значений, например

System Load: 20%
Running Time: 20mins 30sec

Но какой программный компонент должен отвечать за построение текстовых строк?Вы можете возразить:

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

• Представление: должно делать это, поскольку это проблема пользовательского интерфейса, а не часть бизнес-логики.В конце концов, выбор текста не всегда четко отделим от рендеринга.Таким образом, модели не должны беспокоиться о i18n.

Как мне устроиться или подумать об этом разделении труда?Любые идеи?

Примечание 1 : я не думаю, что эта проблема ограничена проектами MVC, хотя здесь я получаю свою терминологию.

Примечание 2 : во время исследования этого вопроса я наткнулся на Presenters и ViewModels .Должны ли они выполнять такую ​​работу, и когда стоит такое правильное / сложное решение, и когда можно просто сделать это в модели или представлении.

Answer 1

Принимая это с точки зрения MVC, если у меня есть данные для отображения в моем представлении, я (почти) всегда создаю модель представления, от которой наследуется представление, со свойствами viewmodel правильного типа для данных.Например, в приведенном выше примере я бы имел SystemLoad в качестве десятичной дроби, а время выполнения в виде количества секунд.Я полагаю, что ответственность за определение того, как эти данные отображаются (как пользователь просматривает их), лежит на представлении.

Использование подхода ViewModel позволяет очень просто определить несколько представлений для представления одних и тех же данных.Контроллеру нужно только знать, чтобы предоставить и получить указанный класс - ViewModel - который затем может быть передан тому, какой наиболее подходящий вид должен быть представлен.Этот рендеринг может быть полноформатным HTML для полнофункциональных браузеров, урезанным для мобильных устройств или даже ответом JSON для API, в любом случае контроллер не нужно менять.обоснование оставить форматирование для просмотра.Используете ли вы viewmodels или нет, эта логика не принадлежит контроллеру

Answer 2

Как общее правило, я бы предложил оставить моделям все, что абстрактно и на взгляд, все конкретное.Например, модель будет иметь system_load: 0.20 и running_time: 1860, но наше представление превратит эти два значения в действительно полезную, просматриваемую информацию.