java - 用于 XML 序列化的持久 BO

Question

使用一组相同的业务对象通过 XML 进行序列化(通过 JAXB 与 JAX-WS 一起使用)并通过 JPA 进行持久化是一个好主意吗？将这两种“范式”合并为一类有缺点吗？

我的一门课看起来例如像这样:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "testSuiteInfo", propOrder = {
    "name",
    "tests"
})
@Entity
public class TestSuiteInfo {

    @Id
    @GeneratedValue
    @XmlTransient
    protected Long id;
    protected String name;
    @XmlElement(nillable = true)
    @OneToMany
    protected List<TestInfo> tests;

    // Getters and setters go here...
}

该类的对象由 JAX-WS 接收，然后由 JPA 保存。

Answer 1

我是 Hyperjaxb3 的作者，XJC 插件，它将 JPA 注释添加到模式派生类中。因此，您只需采用一个模式，然后就能够执行完整的 XML-对象-DB 往返。 MOXy 可以将 JPA 实体映射到 XML as well .

现在回到你的问题。 如果您对数据库、XML 表示和业务逻辑使用相同的类，那么您基本上对所有这三件事都具有相同的模型。如果这对你有用 - 很好!在许多情况下，这确实有效，因为

• BO 通常相当简单
• 对数据库没有具体要求(即性能)
• 您可以控制代表您的 BO 的 XML 架构

在这些情况下，让 XML 对象和对象 DB 具有相同的类是很好的。

现在考虑一个更复杂的情况:

• 您无法控制您的 XML 架构，因为它是交换接口(interface)的某种规范
• 您有性能要求，并且必须相应地对数据库架构进行建模
• 您希望为您的业务逻辑提供经过优化的 BO 代码，其中包含增值方法，而不仅仅是架构派生的内容

所有这些都对您的 XML、JPA 和 BO 部分提出了特定的约束/要求。仅用一种模型(无论是 JAXB 还是 JPA)就能满足所有这些要求吗？不太可能。从规范模式生成 JAXB 类并单独仔细设计 JPA 实体可能会更好。是的，在这种情况下您需要一个映射器，但这是一个较小的弊端。

另请考虑以下问题:

• 如果您的规范架构发生变化，会发生什么情况？如果将发布另一个版本并且您需要支持它？
• 如果您必须在 JPA 或数据库中实现一些新功能怎么办？比如，对某些东西进行非规范化以获得更好的性能？

从另一方面来说，如果你

• 优先使用 XML 模式，不太关心数据库(只需要以某种方式保存事物)或
• 首先采用 JPA，不太关心 XML(只需要序列化 ​​XML 中的内容)并且
• 不要浪费精力编写映射器

那么将 JPA 和 JAXB 放在同一个类中就完全可以了，为什么不呢。 (第一种方法是 Hyperjaxb3，第二种方法是 MOXy)。