DTO模式与JPA Hibernate

huangapple go评论81阅读模式
英文:

DTO pattern with JPA hibernate

问题

我正在按照这个教程学习关于数据传输对象(DTO)的内容,并查看将实体转换为DTO的方法。我想知道"懒加载关系"是什么意思,如果在将其转换为DTO的时刻,我需要获取数据以便将其设置到DTO类中,那么设置"懒加载"和"急加载"有什么区别吗?

英文:

I'm following this tutorial about DTO and checking the way to convert Entity to DTO. I wonder what's the meaning of lazy relationship, if in the moment of converting it to DTO, I need to get the data in order to set it into the DTO class? I always need to get the data first, so does it matter if I set it lazy or eager?

答案1

得分: 0

在惰性加载中,只有在显式调用子类的 getter 方法时,子类的值才会被加载。但是对于急切加载,在调用父类时,所有子类的值都已经被预先加载到其中。
与惰性加载相比,急切加载速度较慢,内存消耗较大。

英文:

In lazy loading child class values are loaded only when getter of child classes are explicitly called. But for eager loading, while invoking parent all its child class have value already loaded in it.
Eager loading is slower and consumes more memory compared to lazy loading.

答案2

得分: 0

我建议你将视角从“我的DTO需要什么”转移出来,因为这会影响判断。

急加载(Eager)与延迟加载(Lazy)实际上是在“我多久需要加载关联关系”和“加载关系会产生多大的开销”之间进行的设计权衡?

举个极端的例子。你有一个持久化实体,比如一个“区域”(Region)。一个“区域”拥有与居住在此“区域”内的所有人(“人物”实体Person)的关联关系。人们(Person)之间彼此认识。

想象一下,你以eager方式获取了这个实体图中的所有内容,并且你有一个需求,需要为一个屏幕加载所有的区域(仅加载区域,而不加载人员)。

急加载所有“区域”将会急加载居住在那里的所有“人物”。但由于人们彼此认识,这也会被急加载,那么你将把整个数据库加载到内存中,只是为了显示区域。

通常情况下,将整个数据库加载到内存中是无法接受的代价。

等等,情况还会更糟。

假设我想编辑单个“人物”。因此我加载了它。这会急加载“人物”的“区域”。它会急加载该区域内的所有“人物”实例。它还会获取这个人物认识的所有其他“人物”,这反过来又会获取这些其他“人物”的“区域”,以递归的方式一直加载下去。

即使对于单个“人物”,我也已经加载了整个数据库。

这是否意味着你永远不应该使用急加载?不是的。

它所意味着的是:当你知道这些数据经常需要一起使用时,你可以进行急加载,并且你可以控制加载所产生的直接和间接数据量。

这就是问题的关键所在:不要为了单个实体加载整个拥有两亿行的表格。

英文:

I suggest you move your point of view out of "what will my DTO need", as this clouds the judgment.

Eager vs. lazy is rather a design tradeoff between "how often will I need the relationships loaded", vs. "how much can it cost to load the relationship" ?

Take an extrême example. You have a persistent entity, say a Region. A Region has a relationships to all people (Person entity) living in this Region. And people (Person) can know each other.

Let's imagine you eager fetch everything in this entity graph, and you have a requirement to load all regions for a screen (not the people, only the regions).

Loading all Region will eagerly load all Person living there. But as people know each other and this will be eagerly loaded too, then you load up the entire database into memory just to display regions.

Loading the whole database into memory usually is an unacceptable cost.

Wait. There's worse.

Say I want to edit a single Person. So I load it. This eagerly fetches the Person's Region. Which eagerly fetches all Person instances in this region. And it also fetches all other Persons this one knows of, which in turn fetches those other Person's Region, and recursively all the way down.

Even for a single Perosn I've loaded the whole database again.

Does that mean you should never have eager fetching ? No.

What it does mean is : you can put eager fetching when you know that data is often needed together, AND you can control the amount of data the fetching will incur, directly AND indirectly.

This is what is at stake : do not load your entire 200 million rows table for a single entity.

huangapple
  • 本文由 发表于 2020年9月19日 17:46:12
  • 转载请务必保留本文链接:https://go.coder-hub.com/63967385.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定