实体的id作为构造函数参数还是通过setter方法？

Question

如果你有一个实体，例如UserEntity，谁的id属性是从数据库中的主键派生的 - 你应该提供一个setter方法，例如setId()吗？

反对的一些论点：

• 打开了可能意外覆盖db
中其他UserEntities的大门
• 两个（或更多）UserEntities可以随时存在，具有相同的id但不同的属性。 （如果我从数据库中提取了3个不同的用户并将其id值设置为相同）

一些论据：

• 如果我没有在构造函数中用id实例化UserEntity（因为它有一个setter方法），我可以使用UserEntity对象的方法和临时/假/新用户值。 ..不必先坚持下去。

提供一个setter（并且不要在构造函数中强制id），或者在构造函数中强制id，并删除setter？

Answer 1

实体的标识值应由持久层管理，理想情况下不能由其他任何东西设置 - 持久层应在持久性时分配新的标识值，并在检索时设置它。此外，您应该能够使用瞬态（非持久）实体而无需访问其身份。允许通过构造函数设置标识可能会导致问题，因为没有标识值的权威来源。可以从外部源分配身份的一个示例是，如果客户端请求新持久性实体具有UUID作为其身份，尽管此示例是设计的。

Answer 2

@johnnietheblack，我更喜欢为实体ID创建私人设定者和公众获取者。验证将存在于setter中（如果需要），我将此id专门设置为构造函数。数字ID实例化为零值，帮助我跟踪它们的生命周期。

Eric Evans的领域驱动设计在Martin Fowler的企业应用程序架构模式深入到这个应用程序的基础架构时讨论了模型域。我相信它们是互补的，我建议。