我正在阅读Eric Evans关于DDD的书,我对以下引用有疑问.如果不使用属性,如何制作equals()方法？我正在使用JPA,并且我有一个唯一的id属性,但在实际持久保存实体之前不会设置.所以你会怎么做？我已经基于属性实现了equals方法,我理解为什么你不应该因为它在我的项目中失败了.
关于实体的部分：
When an object is distinguished by its identity,rather than its
attributes,make this primary to its definition in the model. Keep the
class definition simple and focused on life cycle continuity and
identity. Define a means of distinguishing each object regardless of
its form or history. Be alert to requirements that call for matching
objects by attributes. Define an operation that is guaranteed to
produce a unique result for each object,possibly by attaching a
symbol that is guaranteed unique. This means of identification may
come from the outside,or it may be an arbitrary identifier created by
and for the system,but it must correspond to the identity
distinctions in the model. The model must define what it means to be
the same thing.
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
>使用业务密钥.这是最“符合DDD”的方法.仔细查看域和业务要求.例如,您的企业如何识别客户？他们使用社会安全号码还是电话号码？如果它是基于纸张的(没有计算机),您的企业将如何解决这个问题？如果没有自然业务密钥,请创建代理.选择最终的业务密钥并在equals()中使用它. DDD书中有一节专门讨论这个特定问题.
>对于没有自然业务键的情况,您可以生成UUID.这在分布式系统中也具有优势,在这种情况下,您不需要依赖集中(并且可能不可用)的资源(如数据库)来生成新的ID.
>还有一个选项可以依赖实体类的默认equals().它会比较两个内存位置,在大多数情况下它就足够了,因为Unit Of Work(休眠会话)保留所有实体(这个ORM模式称为Identity Map).这是不可靠的,因为如果你使用不限于一个Hibernate会话范围的实体它会破坏(想想线程,分离的实体等)
有趣的是,“官方”DDD示例使用了一个非常轻量级的框架,其中每个实体类都是使用一种方法从Entity接口派生的：
boolean sameIdentityAs(T other)
// Entities compare by identity,not by attributes.
