将jpa实体转换为宁静资源的好策略是什么?

Restful资源并不总是与您的jpa实体进行一对一映射。 我认为有一些问题,我试图弄清楚如何处理:

  1. 当资源具有由多个实体填充和保存的信息时。
  2. 当实体中有更多信息要作为资源发送时。 我可以使用Jackson的@JsonIgnore但我仍然会遇到问题1,3和4。
  3. 当实体(如聚合根)具有嵌套实体并且您希望包含其嵌套实体的一部分但仅包含某个级别的嵌套作为您的资源时。
  4. 当你想要将一个实体的一部分排除在一个父实体的一部分时,但当它的一部分是另一个父实体时排除一个单独的部分。
  5. Blasted循环引用(我使用Jackson的@JsonIdentityInfo主要使用@JsonIdentityInfo

可能的解决方案:我能想到的唯一方法是处理所有这些问题,就是创建一大堆“资源”类,这些类将具有构造函数,这些构造函数需要实体来构建资源并为此放置必要的getter和setter。资源就可以了。 这有点矫枉过正吗?

为了解决2,3,4和5,我可以在实际实体上进行一些前后处理,然后再将它发送给Jackson,将我的pojo序列化或反序列化为JSON,但这并不能解决问题1。

这些都是我认为其他人会遇到的问题,我很好奇其他人提出的解决方案。 (我目前正在使用JPA 2,Spring MVC,Jackson和Spring-Data,但对其他技术开放)

通过JAX_RS 1.1和Jackson / GSON的组合,您可以直接将JPA实体公开为REST资源,但是您将遇到无数问题。

DTO即对JPA实体的投影是可行的方法。 它允许您将REST的资源表示问题与JPA的事务问题分开。 您可以明确定义表示的性质。 如果仔细设计DTO /投影,则可以控制表示中显示的数据量,包括要遍历的对象图的深度。 您可能需要为同一JPA实体创建多个DTO /投影,以用于可能需要以不同方式表示实体的不同资源。

此外,根据我在JPA实体上使用@JsonIgnore@JsonIdentityInfo等注释的经验并@JsonIdentityInfo完全借助更多可用的资源表示。 在将对象合并回持久性上下文时(由于忽略属性),最终可能会遇到麻烦,或者您的客户端可能无法使用资源表示,因为可能无法理解作为方案的对象引用。 由于缺少标准化,大多数JavaScript客户端通常会在使用@JsonidentityInfo注释生成的对象引用时遇到问题。

通过DTO /预测可以实现其他方面。 JPA @EmbeddedId自然不适合REST资源表示。 一些人主张使用JAX-RS @MatrixParam注释在资源URI中唯一地标识资源,但对于大多数客户端而言,这不是开箱即用的。 矩阵参数毕竟只是一个设计笔记,而不是标准(尚)。 使用DTO /投影,您可以根据计算的Id(可以是组成键的组合)提供资源表示。

注意:我目前正在使用REST的JBoss Forge插件,其中存在部分或全部这些问题,并将通过生成DTO在未来的某个版本中修复。

我同意DTO的其他答案。 他们解决了很多问题:

  1. 分层和清洁代码。 有一天,您可能需要使用不同的格式(例如XML)或接口(例如,基于非Web服务)来公开数据模型。 保持域模型中每个接口/格式的所有配置(例如@JsonIgnore@JsonidentityInfo )都会非常混乱。 DTO将这些问题分开。 它们可以包含外部接口(Web服务)所需的所有配置,而不涉及域模型的更改,这可以保持Web服务和格式不可知。

  2. 安全性 – 您可以轻松控制客户端的内容以及允许客户端修改的内容。

  3. 性能 – 您可以轻松控制发送给客户端的内容。

  4. 诸如(循环)实体引用,延迟加载的集合等问题也会由您转换为DTO时明确且明知地解决。

鉴于您的约束,看起来除了数据传输对象之外没有其他解决方案 – 是的,它的发生频率足以让人们命名这种模式……

如果你的应用程序完全是CRUDish,那么走的路就是Spring Data REST,你绝对不需要DTO。 如果它比这更复杂,那么使用DTO保护应用层将更安全。 但是不要试图将DTO封装在控制器层内。 它们属于服务层,因为映射也是逻辑的一部分(您在应用程序中提供的内容以及您从中提取的内容)。 这样应用层保持密封。 当然,在大多数情况下,它可以是这两者的混合。