实体(假设为UserEntity)对其属性具有严格的规则，它可以以2种状态存在-持久(表示其具有id)和预持久(表示其尚无id)。
根据对this question about how to handle required properties的回答，只有在传递了id到其构造函数的情况下，才可以创建“真实的” UserEntity。
但是，当我需要根据浏览器发送的信息创建new UserEntity时，我需要能够在持久化到数据库之前验证信息。
过去，我只是创建一个空白的UserEntity(不带id)，设置新属性，然后对其进行验证-但是，在这种更加安全的实体新思考方式中，我永远不要创建一个新的UserEntity没有id。
我不想创建两个知道如何验证我的UserEntity属性的地方，因为如果它们发生更改(并且会更改)，那么更新代码的次数将增加一倍，并且出现错误的机会也会增加一倍。
如何有效地集中实体属性的验证知识？
注意
我想到的一个想法是in this question，其中我考虑将非状态属性(如电子邮件，密码和名称)存储在标准化值对象中，该对象将了解其不同服务(如Controller，Validator和Repo)的属性规则。 ，或Mapper可以使用。
最佳答案
那就是工厂的目的。在工厂方法中，您只传递了强制执行UserEntity的实际不变量所需的数据(花一些时间来找出UserEntity的实际真正的不变量是什么，最好与您的域专家一起进行)。
在工厂方法中，您将创建一个新ID并将其传递给UserEntity构造函数。
在这个阶段，我认为如果构造函数内部的验证失败，则放弃该实例不是很糟糕。在最坏的情况下-您丢失了一个ID ...这种情况不会经常发生-大多数情况下，应该在客户端中验证数据。
当然，另一个选择是，在工厂方法中，您首先要验证参数，然后才创建一个新的ID并将其传递给UserEntity构造函数。
itzik saban