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

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

ETA:

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

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

Design Patterns 101.

Model - для хранения данных (обычно поддерживаемых базой данных).

View - для представления данных (а не манипулирования ими).

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

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

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

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

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

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

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

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

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

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

messages_en-US.properties

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

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

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

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

Walter

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

Чтобы объяснить, что такое "вид":

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

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

Пример:

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

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

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

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