ORM /如何应对Domain对象和持久对象之间的对应关系? [英] ORM / How to deal with the correspondence between Domain object and Persistent object?

查看:235
本文介绍了ORM /如何应对Domain对象和持久对象之间的对应关系?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在应用程序中,至少有两种方法处理域对象持久化和ORM。

In an application, there are at least two ways for dealing with domain object persistence and an ORM.


  • 直接映射域对象持久化使用某种类型的ORM(XML或注释)

  • 制作的在您的域和你的持久化模型之间有很多的阻抗失配的情况下关注分离(表列)。这意味着,域对象是持久性无关,也有一些转换一些相应的持久对象,后者映射到一个ORM。

  • Mapping directly the domain object to persistence using some kind of ORM (xml or annotations)
  • Making separation of concerns in case of a lot of impedance mismatch between your domain and your persistent model (table columns). That means, domain object is persistence agnostic and there are some conversions to some corresponding persistent object, this latter maps to an ORM.

由于纯DDD开发人员都知道,域名不应该的驱动按您的数据库需求,因而在我的项目,我用这种分离的关注。有人会认为YAGNI的,有人会说大(像的这里)。我的项目需要一些不同的数据库,根据我的需要重用性,所以我选择了我的域模型和我的持久化模型之间的关注点分离。
但是我碰到一个问题(一些性能损失),与Spring的数据。
一个细节或许,但只是承担与一个ORM不具有的functionnality合并,或任何东西,以分离的实体重新连接到当前事务。

As pure DDD developers know, domain should not be driven by your database needs, thus in my project, I use this separation of concerns. Someone would think of YAGNI, someone would say "great" (like here). My project will need some different databases according to my need of reusability, so I chose the separation of concerns between my domain model and my persistent model. But I came across an issue (some kind of performance loss), with Spring-Data. A detail maybe, but just assume an ORM that doesn't have the functionnality of merge, or anything related, to reattach detached entities to the current transaction.

要理解,让我们假设这个概念的代码(在Java中):

To understand, let's suppose this conceptual code (in 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
  }
}

但是,如果从今以后,持久性的持久化模型时,不能直接域模型,我们就失去了attachement,因为从域名持久化对象的转换过程中(事实上,库将现在与持久化对象(而不是域模型直接处理)而仅仅是将结果转换为中, managedEntity 状态丢失域对象作为返回类型)。

But if henceforth, persistence occurs on the persistent model, not the domain model directly, we'd lose the attachement, since during conversion from domain to persistent object (indeed, repositories would now deal with persistent objects (instead of domain model directly) and merely convert the result as domain object as return type), the managedEntity state is lost.

    @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
          }
        }

下面的问题:
虽然从用户转换为 UserPO (在我的基础设施层),我失去了实体附件。因此,在 userRepository.participateToMeeting 方法,我一定要找回 UserPO MeetingPO 再从数据库(以使它们附后)......因此,涉及两个额外的请求。

Here's the issue: While converting from User to UserPO (in my infrastructure layer), I lose the entity "attachment". Thus, in the userRepository.participateToMeeting method, I have to retrieve UserPO and MeetingPO again from database (to make them attached)...therefore involving, two additional requests.

有一个更好的做法来处理转换域对象/没有这种性能损失持久化对象?

Is there a better practice to deal with conversions domain object/persistent object without this performance loss?

推荐答案

我的链接文章不同意。虽然我同意,领域模型和持久化模型之间的关切是不同的,一个ORM的整个目的就是一个域模型和持久性模型之间进行映射。由于ORM应该提供映射,创建一个额外的类层次结构,以方便映射是矫枉过正,并可能导致像你描述一个问题。该域模型类似于数据模型实际上的确是远远超过了单纯的巧合。相反,它们是同一个域的两个代表方面,因此应具有高度的一致性。在ORM旨在解决一个对象模型和相应的关系模型之间的失配。有些情况下映射遇到困难的情况下,但在NHibernate的,例如,这些都可以通过实现自定义用户类型组件映射解决。

I disagree with the linked article. While I agree that the concerns between the domain model and the persistence model are different, the entire purpose of an ORM is to map between a domain model and a persistence model. Since the ORM is supposed to provide that mapping, creating an additional class hierarchy to facilitate mapping is overkill and can lead to problems like the one you're describing. The fact that the domain model resembles the data model is indeed far more than a mere coincidence. Instead, they are both representing aspects of the same domain and should therefore have a high degree of correspondence. The ORM is designed to address the mismatch between an object model and a corresponding relational model. There are cases where mapping gets tough, but in NHibernate for example, these can be addressed by implementing custom user types for component mappings.

这篇关于ORM /如何应对Domain对象和持久对象之间的对应关系?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆