Всем здравствуйте. Прочитал тут одну статью http://www[dot]elisdn[dot]ru/blog/104/do[dot][dot][dot]tities-modelling . Если я все правильно понял, то тут нужно описывать сущность другими сущностями. Вот например пользователь. У него есть идентификатор, юзернейм, пароль и статус. Нужно ли каждое из этих свойств описывать отдельным классом? Или есть какие то пределы разумного?
Объясните мне пожалуйста.
1. psevdo - 24 Октября, 2017 - 14:08:05 - перейти к сообщению
2. LIME - 25 Октября, 2017 - 04:54:41 - перейти к сообщению
не сущностями, вернее не обязательно ими, а объектами-значениями
это сделает структуру более гибкой и прогнозируемой, но одновременно и усложнит
объекту в отличии от литерала можно добавить поведение
например при смене пароля сразу его хэшировать в методе объекта-значения а не в сущьности или контроллерах/сервисах
получаем всегда валидное значение вместо валидации потенциально кривой сущности
решать тебе
(Добавление)
вспомнил пример
надо было при выводе id заказа добавлять букву префиксом в зависимости от филиала
типа A100500
можно сделать это в гетере
тогда не получится $order->getId() === 100500
можно сделать разные гетеры типа getId(), getPrefixId()
но надо всегда об этом помнить, не сложно но как-то ...
а можно id сделать объектом и реализовать ему __toString
подмешали поведение значению
а если придется сделать несколько поведений то в сущьности измываться над литералом становится все сложнее
опять же можно менять структуру значения не меняя ничего кроме класса объекта-значения
сегодня это строка а завтра склеенный массив
(Добавление)
Любую проблему можно решить введением дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракции
https://developerslife[dot]ru/8729 ))
это сделает структуру более гибкой и прогнозируемой, но одновременно и усложнит
объекту в отличии от литерала можно добавить поведение
например при смене пароля сразу его хэшировать в методе объекта-значения а не в сущьности или контроллерах/сервисах
получаем всегда валидное значение вместо валидации потенциально кривой сущности
решать тебе
(Добавление)
вспомнил пример
надо было при выводе id заказа добавлять букву префиксом в зависимости от филиала
типа A100500
можно сделать это в гетере
тогда не получится $order->getId() === 100500
можно сделать разные гетеры типа getId(), getPrefixId()
но надо всегда об этом помнить, не сложно но как-то ...
а можно id сделать объектом и реализовать ему __toString
подмешали поведение значению
а если придется сделать несколько поведений то в сущьности измываться над литералом становится все сложнее
опять же можно менять структуру значения не меняя ничего кроме класса объекта-значения
сегодня это строка а завтра склеенный массив
(Добавление)
Любую проблему можно решить введением дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракции
https://developerslife[dot]ru/8729 ))
3. psevdo - 25 Октября, 2017 - 10:26:30 - перейти к сообщению
LIME пишет:
Думал по ссылке будет что-то полезное)
В итоге что получается... Возьмем для примера Id. Если мы знаем, что данное свойство объекта мы будем получать как оно есть, т.е. просто значение, то можно описывать его простым литералом. Но если будет какая-либо логика в дальнейшем, то описываем объектом-значением.
4. LIME - 25 Октября, 2017 - 10:47:04 - перейти к сообщению
может оказаться не так-то просто заменить литерал на объект
почему свойства сразу делают приватными и лепят гетеры?
однозначного универсального рецепта у меня нет
почему свойства сразу делают приватными и лепят гетеры?
однозначного универсального рецепта у меня нет
5. LIME - 26 Октября, 2017 - 09:00:25 - перейти к сообщению
и что-то полезное по ссылке https://www[dot]youtube[dot]com/watch?v=rjtbCyacJas