"Кошерна" ли такая логика модели в Yii2?

Question

[Дмитрий Ким]

Есть модель пользователя, дата рождения в которой в базе MySQL хранится в поле DATE в формате «Y-m-d» (типичная ситуация). Для пользовательского ввода предусмотрен другой формат даты «d.m.Y» (частый случай). Тогда логика такая:

public function afterFind()
{
    parent::afterFind();
    $this->birthdate = \Yii::$app->formatter->asDate(\DateTime::createFromFormat('Y-m-d', $this->birthdate), 'php:d.m.Y');
}

public function beforeSave($insert)
{
    if (parent::beforeSave($insert)) {
        $this->birthdate = \Yii::$app->formatter->asDate(\DateTime::createFromFormat('d.m.Y', $this->birthdate), 'php:Y-m-d');
        return true;
    }
    return false;
}

Допустим пользователь ввёл «01.12.1980», мы проверяем что дата корректая, сохраняем модель, модель сохраняет дату как «1980-12-01», далее мы отправляем модель на клиент и получаем дату в "непотребном" для пользователя формате. Логично было бы снова превратить сохраненную дату в "нормальный формат", или еще логичнее дёрнуть тригер, где у нас это уже происходит:

public function afterSave($insert, $changedAttributes)
{
    parent::afterSave($insert, $changedAttributes);
    $this->trigger(self::EVENT_AFTER_FIND);
}

Насколько это правильно и "кошерно"? Или предложите другую логику?

Comments

[Lander]

А через геттер и сеттер не пробовали?

[Дмитрий Ким]

Lander, это мне нужно создать виртуальное поле для модели, добавить его в правила валидации, а при сохранении брать значение даты из виртуального поля, форматировать в нужный формат и присваивать основному?

[Lander]

Дмитрий Ким, да. Но это как идея...
Во всяком случае я делал так.

Answer 1

[Дмитрий]

Добрый день.
Я думаю, что это лишнее.
Храните дату в timestamp, а при выводе пользователю форматируйте дату как Вам будет угодно.
В базе "data_birthday INT(11)". При выводе Вы будете получать что-то подобное "1497301200".
При выводе даты пользователю форматировать как обычно, при помощи Yii::$app->formatter->asDate(****).
Если это в админке, то в GridView, например, достаточно указать формат даты:

'columns' => [
    'date_birthday:date'
]

Или

'columns' => [
   'attribute' =>  'date_birthday',
   'format' => 'date',
]

При таком варианте Вам надо подправить правила валидации в модели.

Comments

[Дмитрий Ким]

Форматирование даты на странице - это не проблема. Но как тогда потом ее сохранить в базу опять в формате TIMESTAMP? Всё равно в модели делать преобразование.

[Дмитрий Ким]

TIMESTAMP годится для хранения точного времени, например времени обновления контента. А дата рождения не должна хранится в таком формате. Кроме того, поле DATE удобнее и быстрее в плане поиска по дате.

[Дмитрий]

Но как тогда потом ее сохранить в базу опять в формате TIMESTAMP?

Например при валидации.

А дата рождения не должна хранится в таком формате

Я Вам дал пример, дорабатывайте под свои нужды. Но гонять туда-сюда через formatter....

Answer 2

[Максим Федоров]

Не кошерна. Модель должна отвечать за логику а не за преобразование данных для пользователя. За формат отображения должно отвечать представление и соответственно оно должно преобразовать формат Y-m-d в d.m.Y и обратно. Кроме того таким подходом Вы размазываете логику форматирования по всему приложению (а когда необходимо будет поменять формат придется лопатить все приложение...)

Comments

[Дмитрий Ким]

Интересно, как я заставлю представление форматировать дату перед сохранением?

[Максим Федоров]

Дмитрий Ким, например с помощью JS, что мешает на уровне JS перед отправкой форматировать дату в такой вид, который нужно серверу?

[Дмитрий Ким]

а когда необходимо будет поменять формат придется лопатить все приложение...

Тогда придётся лопатить весь javascript код во всех местах использования данного поля?

[Максим Федоров]

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

[Дмитрий Ким]

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

[Максим Федоров]

Дмитрий Ким, в основном с консолью работают люди который привыкли к формату Y-m-d так то думаю для них это не будет проблемой, Этот формат де факто уже является стандартным. Вообще формат в стиле d.m.Y это по сути дела формат локализации, и для каждой страны (ну почти для каждой) он может быть разным

Answer 3

[vism]

А в yii нет сеттеров гетеров для атрибутов или мутаторов?
Вобще оптимально преобразовывать в Carbon при получении и парсить Карботом при установке атрибута и готовить для сервера.
Эта логика Кошерна и очень верна(но желательно сетерами и гетерами)
Вы в 1 месте данные готовите для получения и установки.

Answer 4

[VaNnOrus]

Имхо, форматировать вывод в моделе - это вообще не по феншую и смысла в этом никакого не наблюдается. За форматирование данных в MVC по концепции должно отвечать представление "V". Во всех остальных местах данные должны быть в том формате, в каком они хранятся.
А обработка пользовательского ввода должна проходить в превалидации. Если вы перед сохранием данных преобразование делаете, то как проходит валидация? В валидации в том числе предполагается проверка соответствия формату.

Answer 5

[yiiworld]

Сам вопрос задан не "кошерно" ))
Вар.1) логика вашего AfterFind (для отображения) действительно должна быть только в представлении. Т.е. работать с данными в модели удобнее в едином формате(например в том формате в котором вы их получаете из БД) (кроме случаев когда это невозможно).
Вар.2) нахождение логики подготовки данных в BeforeSave немного не кошерно т.к. данные до отображения и после получения будут иметь разный формат. Поэтому предпочтительно эту логику выполнить там где данные были получены(например входящий POST в контроллере)
Вар.3) А для вашего "Хочется "целостности"" - тут "плясать" надо от формата данных с которым вы работаете в модели(опорный формат). В таком случае:
- перед сохранением(для проверки соответствия и преобразования) используете валидацию (см.Автономные валидаторы) или [не так кошерно]beforeSave()
- после получения из БД выполняете преобразование в afterFind()
- для отображения выполняете преобразование в представлениях
- для получения из запроса выполняете преобразование в контроллере
и все эти 4 функции(static) приспокойненько располагаете в базовой модели(или основной, если нет базовой) и дергаете их по мере необходимости.
PS: ответы про сеттеры и геттеры это конечно хорошо, но они как таковые просто инструмент а не решение (для Вар3 можно сделать геттеры(и по необходимости сеттеры) для каждого случая(и соответственно 4 виртуальных атрибута), а можно использовать функции преобразования напрямую)
PPS: товарищ Максим Федоров, который за форматирование на JS, пишет уж совсем глупые вещи(читайте комментарии про js и общую архитектуру), (ИМХО). Но тут и диссонанс - в других ответах на тостере он вполне себе здраво рассуждает.

Comments

[Максим Федоров]

товарищ, а в чем собственно глупость? что-то не вижу аргументов с Вашей стороны

[yiiworld]

Максим Федоров, конкретно в вашем ответе на вопрос

Интересно, как я заставлю представление форматировать дату перед сохранением?
Написано 12 окт.
Нравится Ответить
qonand Максим Федоров @qonand
Дмитрий Ким, например с помощью JS, что мешает на уровне JS перед отправкой форматировать дату в такой вид, который нужно серверу?

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

[Максим Федоров]

yiiworld, окей, давайте посмотрим на задачу в разрезе паттерна MVC, который используется в Yii (ну или точнее его подобие, если не вдаваться в детали). Где расположить форматирование данных?
В модели? Что такое модель в MVC? Набор классов отвечающий исключительно за бизнес-логику. Бизнес-логика должна быть изолирована от внешнего мира и должна не зависеть от способа отображения данных. Да без проблем можно сделать что бы модель отвечала за форматирование данных, только это уже не MVC будет а просто говнокодерская каша.
В контроллере? Что такое контроллер в MVC? некий класс или кусок кода отвечающий за обработку запроса пользователя. Разместить логику форматирования данных в контроллере в принципе можно, хоть это и спорное решение (философствовать на тему можно ли считать форматирование данных логикой обработки запроса не буду...). Окей, можно разместить форматирование в контроллере, но если Ваш сайт будет работать с несколькими странами в которых формат отображения дат имеет разный вид Вам придется "раздувать" код контроллера, определять в нем в каком формате пришли данные (контроллер же просто получает запрос и не знает что и как у пользователя отображается), как их преобразовывать. В общем очень не практичный и не универсальный вариант, да и делать лишние операции на сервере, которые можно сделать на клиенте, тем самым потребляя лишние ресурсы не очень хорошо.
В представлении? Что такое представление в MVC? по сути дела это внешний вид системы. Формат данных - это часть внешнего вида, т.к. он описывает как пользователь будет видеть систему. Кроме того представление однозначно, в отличии от контроллера, знает что и в каком формате отображается. Поэтому гораздо правильнее и с точки зрения MVC и с точки зрения чистоты кода переложить всю ответственно за форматирование данных на представление, а в данном случае на js-виджет (как часть представления) который будет хранить в себе отображаемый формат и производить манипуляции с ним.

[yiiworld]

Максим Федоров, к чему столько текста? я указал на конкретное замечание "если вы действительно предлагаете перед сохранением форматировать данные на стороне клиента(js), то это и есть глупость."
И MVC с YII тут ни причем. Этот вопрос можно закрывать т.к. понятно что серверная валидация-преобразование в клиент-серверной архитектуре не случайно появилась.

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

[Максим Федоров]

yiiworld,

если вы действительно предлагаете перед сохранением форматировать данные на стороне клиента(js), то это и есть глупость.

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

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

не все что придумано нужно использовать и не везде. Преобразование преобразованию рознь.

Обратите внимание что MVC является надстройкой над предметной областью решаемой задачи, и эта предметная область варьируется в зависимости от ситуации.

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

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

о дааа, статические методы, наследование по функционалу ... прям "Best practice" по ООП

На сей ноте моего превосходства можно закончить))

Ну по изобретению костылей Вы превосходны спору нет, ну да ладно продолжать спор не вижу смысла, дело то Ваше - хотите не следуйте ООП, забивайте болт на архитектурные решения, и радуйтесь жизни до первого попавшегося крупного и долгоживущего проекта

[yiiworld]

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