MVC - кто форматирует модель?

Question

Перед рендерингом в представление модель должна быть отформатирована:

1. локализованные многоязычные данные;
2. дата, значения времени отформатированы;
3. числа отформатированы.

Кто выполняет все это форматирование - Controller или View?

Прав ли я, что все форматирование выполняется контроллером, который создает так называемую модель представления, содержащую только отформатированные значения, и отправляет эту модель просмотра в представление?

Заранее спасибо!

Answer 1

Эрик Петроэль прав, но я бы создал вспомогательный класс (ы) для получения локализованного контента / дат и т. Д., Потому что локализация не всегда в представлениях, например отправка писем с локализованным контентом. Я хотел бы иметь что-то вроде LocalisationHelper.GetString ("MyKey") или LocalisationHelper.GetDate (Date.Now), где LocalisationHelper знает текущую локаль пользователя (возможно, из сеанса).

Затем используйте это непосредственно в представлениях, где это возможно:

<%= Html.Encode(LocalisationHelper.GetDate(Date.Now)) %>

Answer 2

Шаблоны проектирования 101.

Модель предназначена для хранения данных (обычно при поддержке базы данных).

Просмотр предназначен для представления данных (без манипулирования ими). ​​

Контроллер предназначен для манипулирования моделью и передачи ее в представление (например, здесь будет выбран правильный языковой стандарт).

MVC не обязательно означает, что у вас есть 3 различных класса, а скорее 3 компонента или слоя. Они абстрактны и не обязательно должны быть привязаны к одному физическому классу. Внутри вашего уровня Controller, который может состоять из любого числа вспомогательных классов или чего-либо еще.

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

У меня была дискуссия с нашей командой об использовании аннотаций для отображения форм на веб-странице. Эти аннотации были помещены в модель или класс сущности. Вы часто будете работать напрямую с классами сущностей, поэтому это устранит некоторые накладные расходы и дублирование усилий, если вы разместите здесь свои аннотации. Поскольку ваши аннотации размещаются непосредственно в классе модели, вы не можете получить представление о дне рождения, это просто невозможно. Кроме того, следуя шаблонам, вы удаляете мусор, который не добавляет ценности к конечному результату. Вы просто пишете бизнес-логику и больше ничего не знаете.

Хотя аннотации были в том же классе, что и уровень модели, уровень представления или представления состоял из аннотаций и вспомогательных классов. Он не обязательно должен быть отдельными классами или границами.

Другой пример. Я работал над некоторыми PHP веб-приложениями в прошлом. Я использую приложения, потому что они были монолитным блоком кода, более или менее единственным основным методом со всей логикой (что вряд ли является функциональным приложением).

Если вы не абстрагируете код в функции и просто используете один метод, у вас будет много дублирования усилий. Если бы вы попытались понять этот монолитный кодовый блок, у вас возникла бы куча неприятностей (как и мне, было трудно узнать, что происходит, тогда я нашел бы подобный блок кода где-то еще и был бы ошеломлен, почему некоторые вещи были изменены так, как они были).

Это можно сделать любым способом, но шаблоны проектирования, такие как MVC, помогут вам упростить то, что вы пишете, чтобы заставить его работать, а также упростить процесс решения. Другой популярный шаблон дизайна или подход - разделяй и властвуй.

Чтобы ответить на ваши оригинальные вопросы:

В Java локализованные данные будут выполняться приложением прозрачно. Например, если вам нужна поддержка языкового стандарта США, вы должны создать файл свойств:

messages_en-US.properties

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

Для моего приложения у меня есть целые страницы на другом языке, так что я делаю вот что. Мой контроллер определяет локаль клиента или лучшее соответствие. Затем он выбирает, какое представление отображать, и передает модель (данные) в представление.

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

Я использую JBoss Seam, поэтому шаблон проектирования MVC все еще используется, но более абстрактно. У меня нет настоящих «контроллеров», но есть перехватчик, который отвечает за обработку определенной части функциональности (определение локали клиента, затем другой для их предпочтения даты / времени). Мои контроллеры, которые будут эквивалентны Spring Controller, являются компонентами действий, отвечающими за обработку действий страницы.

Вальтер

Answer 3

Представление отвечает за это , а не за контроллер.

Чтобы объяснить, мне нужно немного пояснить, что такое «представление»:

Как в веб-шаблонах, так и в традиционных шаблонах MVC GUI представление отвечает за внешнее представление любых частей модели, которые отображаются . Если это означает «форматирование» данных из модели, пусть будет так.

Контроллер не должен форматировать данные - потому что контроллер отвечает за действия с моделью на основе событий / команд, поступающих из внешнего мира. Контроллер не имеет ничего общего с рендерингом вывода.

Пример:

Я хочу отобразить корзину с несколькими строками заказа:

• Добавление вещей в корзину приводит к тому, что контроллер меняет содержимое модели корзины.
• Изменение моего языкового стандарта приводит к тому, что контроллер меняет настройку в пользовательской модели, чтобы указать предпочтительный языковой стандарт.
• Всякий раз, когда отображается корзина, представление должно запрашивать у модели строки заказа и решать, как это отобразить - возможно, выполнять работу с учетом региональных настроек.
• Один и тот же клиент может попросить просмотреть корзину в нескольких разных валютах. Это просто означает изменение того, как оно выглядит в представлении. Это та же самая корзина покупок для того же покупателя с теми же вещами.
• Если это веб-приложение, созданное на страницах веб-шаблонов, вы можете встроить код для извлечения локализованных сообщений, например, <%= message_renderer.text(:insufficient_funds) %>. В этом случае «message_renderer» и файл шаблона являются частью представления.

Представления не обязательно являются просто веб-шаблонами. В некоторых основанных на Java фреймворках, например, мы помещаем «объекты просмотра» в шаблон скорости. Эти объекты представления связаны с объектами в модели, но они также выполняют поведение при отображении и форматировании по требованию. Это часть представления, хотя это не просто шаблон.

Это немного сбивает с толку фреймворки, такие как ruby ​​на рельсах и groovy на grails, где они называют шаблон «представлением» - когда представление действительно больше, чем просто шаблон. Традиционно (в Smalltalk MVC и в Java Swing) представления - это просто код, который может выполнять форматирование, рендеринг и любое другое поведение, связанное с отображением.

Answer 4

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

ETA:

Я бы не стал выступать за то, чтобы объекты уровня службы вызовов в общем смысле представлялись объектами, но я думаю, что для локализации это имеет смысл.

Например, допустим, у вас есть много статического текста на ваших страницах, который вы токенизировали и сохранили в базе данных в различных локализованных формах. Я не думаю, что для контроллера имеет смысл искать и помещать все эти текстовые токены в модель. Хотя поиск текстовых токенов технически является операцией «уровня службы», я все же думаю, что представлению имеет смысл вызывать эту службу напрямую через некоторый служебный класс, а не заставлять контроллер это делать.