3

在应用程序中，至少有两种方法可以处理域对象持久性和 ORM。

  • 使用某种 ORM（xml 或注释）将域对象直接映射到持久性
  • 如果您的域和持久模型（表列）之间存在大量阻抗不匹配，请分离关注点。这意味着，域对象与持久性无关，并且有一些转换为一些相应的持久性对象，后者映射到 ORM。

正如纯 DDD 开发人员所知，域不应该由您的数据库需求驱动，因此在我的项目中，我使用这种关注点分离。有人会想到 YAGNI，有人会说“很棒”（比如这里）。我的项目将根据我对可重用性的需要需要一些不同的数据库，所以我选择了我的领域模型和我的持久模型之间的关注点分离。但是我遇到了 Spring-Data 的一个问题（某种性能损失）。可能有一个细节，但只是假设一个 ORM 没有 的功能merge或任何相关的功能，将分离的实体重新附加到当前事务。

为了理解，让我们假设这个概念代码（在 Java 中）：

@Transaction
public void participateToMeeting(String userId, String meetingId){
  User user = userRepository.ofId(userId);  //returns a User domain type
  Meeting meeting = meetingRepository.ofId(meetingId); //returns a Meeting domain type
  if(user != null && meeting != null) {
    user.participate(meeting);    // as attached entity, this would automatically persist the relationship
  }
}

但是，如果从今以后，持久性发生在持久性模型上，而不是直接在域模型上，我们将丢失附件，因为在从域到持久性对象的转换期间（实际上，存储库现在将处理持久性对象（而不是直接处理域模型）和只需将结果转换为域对象作为返回类型），managedEntity状态就会丢失。

    @Transaction
        public void participateToMeeting(String userId, String meetingId){
          User user = userRepository.ofId(userId);  //returns a User domain type (converted from UserPO to User)
          Meeting meeting = meetingRepository.ofId(meetingId); //returns a Meeting domain type (converted from MeetingPO to UserPO)
          if(user != null && meeting != null) {
            userRepository.participateToMeeting(user, meeting); 
//although not conventional, adding this kind of method allows to convert User and Meeting to some persistent object: UserPO and MeetingPO, before proceeding to persistence
          }
        }

这是问题所在：从转换User为UserPO（在我的基础架构层中）时，我丢失了实体“附件”。因此，在该方法中，userRepository.participateToMeeting我必须 再次从数据库中检索（以使它们附加）......因此涉及两个额外的请求。UserPOMeetingPO

是否有更好的做法来处理转换域对象/持久对象而不会造成这种性能损失？

4

1 回答 1

3

我不同意链接的文章。虽然我同意域模型和持久性模型之间的关注点不同，但 ORM 的全部目的是在域模型和持久性模型之间进行映射。由于 ORM 应该提供该映射，因此创建一个额外的类层次结构来促进映射是多余的，并且可能导致像您描述的那样的问题。领域模型与数据模型相似的事实远非巧合。相反，它们都代表同一领域的各个方面，因此应该具有高度的对应关系。ORM 旨在解决对象模型和相应的关系模型之间的不匹配问题。在某些情况下映射变得困难，但在 NHibernate 中，例如，

于 2013-07-15T17:05:10.810 回答