У меня есть UserEntity, который в конечном итоге сохраняется в БД в соответствии с его свойством id. В этом случае свойство id явно чувствительно, потому что его изменение приведет к тому, что UserEntity будет сохранен поверх другого UserEntity при сохранении позже.
Поэтому я хотел бы помочь защитить себя от чего-то подобного ...
Вариант 1. Заставляю ли я id передаваться в конструктор, тем самым удаляя сеттер?
- Это будет означать, что каждый UserEntity, которому дается хранилище, будет действительным (потому что он имеет минимальное требование
id).
- Недостатком является то, что мой контроллер не смог бы создать новый UserEntity (), потому что у него не было бы
id, чтобы дать его.
Вариант 2. Разрешить Id в конструкторе быть нулевым, но не предоставлять Setter
- Это, по сути, создаст два типа объектов UserEntity: те, которые были сохранены, и те, которые не сохранились.
- Я мог бы создать новый UserEntity () где угодно, заполнить его значениями, затем передать в репозиторий, который затем сохранит его, создаст новый UserEntity с новым
id и вернет его.
- Это круто, но означает, что мне нужно дважды проверить, что у моей сущности есть
id везде, где я хочу использовать ее для сохранения / логики домена / и т. Д., Чтобы убедиться, что это сохраненная сущность.
Вариант 3. Не беспокоюсь ли я так, и предоставил для этого сеттер?
- Это создает риск изменения
id объекта UserEntity и перезаписи другого объекта UserEntity в БД.
- С другой стороны, я могу создать новый UserEntity (), не зная заранее
id, который я могу передать в свой репозиторий для сохранения.