Идентификатор объекта в качестве аргумента конструктора или через метод установки?

Question

Если у вас есть сущность, такая как UserEntity, свойство id которого является производным от его первичного ключа в БД, - следует ли указать метод установки, такой как setId()?

Someаргументы против:

• открывает дверь для возможных случайных перезаписей других UserEntities в db
• две (или более) UserEntities могут существовать в любое время с одинаковыми id но разные свойства.(если я вытащил 3 разных пользователей из БД и установил их значения id на одно и то же)

Некоторые аргументы для:

• ifЯ НЕ ДОЛЖЕН создавать экземпляр UserEntity с id в конструкторе (так как он имеет метод setter), я могу использовать методы объекта UserEntity с временными / поддельными / новыми пользовательскими значениями ... без необходимости сохранениясначала.

Предоставить установщик (и не вызывать id в конструкторе) или принудительно id в конструкторе и удалить установщик?

Answer 1

Значением идентичности объекта должен управлять уровень постоянства, и в идеале он не должен устанавливаться ничем другим - уровень постоянства должен назначать новое значение идентификатора при сохранении и устанавливать его при извлечении.Кроме того, вы должны иметь возможность использовать временную (не постоянную) сущность без необходимости доступа к ее идентификатору.Разрешение идентификации через конструктор может привести к проблемам, потому что нет никакого авторитетного источника значений идентичности.Один пример, в котором идентификационные данные могут быть назначены из внешних источников, - это если клиент запрашивает, чтобы у нового персистентного объекта был UUID в качестве идентификатора, хотя этот пример является надуманным.

Answer 2

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

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