域类通常会获得 JPA 或 JAXB 注释,还是两者都有?

发布于 2024-08-12 17:00:29 字数 413 浏览 1 评论 0原文

我有一个 Java 企业应用程序,它提供 Web 服务、一个域层和一个 hibernate 持久层。在这种特殊情况下,我通过线路发送的对象、域对象和持久性对象之间(目前)没有很大的差异。

目前,应用程序在持久性方面使用 DTO,并使用 JAXB 注释来注释域类。然而,我读得越多、思考得越多,就越觉得这是倒退的! (更不用说有大量代码支持 DTO 和域对象之间的无意识来回。) 似乎大多数架构师都建议将 JPA 注释放在域模型上并创建 DTO 用于通过网络发送对象。

就我而言,我可以将 JAXB 和 JPA (Hibernate) 注释都放在我的域类上吗?

将我的 Web 服务外观、我的域和我的持久性紧密捆绑在一起的想法似乎很容易维护,但确实让我担心,因为这些可能需要及时更改。但是,为 Web 服务端创建一组 DTO 类并为持久性端跳过 DTO 会更明智吗?

I have a Java enterprise application that provides a web service, has a domain layer, and a hibernate persistence layer. In this particular case, there is not a huge difference (at the moment) between the objects I send over the wire, the domain objects, and the persistence objects.

Currently the application uses DTO's on the persistence side and annotates the Domain classes with JAXB annotations. However, the more I read and think about it, the more this seems backwards! (Not to mention there is a lot of code to support the mindless back and forth between the DTO's and the Domain objects.) It seems like most architects suggest puting JPA annotations on the domain model and create DTO's for sending objects over the wire.

In my case, could I put both the JAXB and JPA (Hibernate) annotations on my domain classes?

The thought of keeping my web service facade, my domain, and my persistence all tightly bundled together seems easy to maintain, but does concern me as these may need to change in time. But would it be smarter to create a set of DTO classes for the web services side and skip the DTO's for the persistence side?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

盛装女皇 2024-08-19 17:00:29

没有使用 JPA 和 JAXB 注释来注释同一个类的功能原因,我自己有时也这样做过。不过,它确实变得有点难以阅读,有时您需要在 JAXB 和 JPA 之间进行不同的类设计权衡。根据我的经验,这些权衡通常意味着您最终会得到两个类模型。

There's no functional reason for not annotating the same class with both JPA and JAXB annotations, I've done it myself on occasion. It does become a bit hard to read, though, and sometimes you want different class design trade-offs with JAXB and JPA. In my experience, these trade-offs usually mean you end up with two class models.

薄荷港 2024-08-19 17:00:29

我同意使用相同的模型类是正确的方法。如果您担心注释混乱,可以使用 JAXB 实现(例如 EclipseLink JAXB) 提供了一种外部化元数据的机制:

另外,由于您使用的是 JPA 模型,EclipseLink JAXB (MOXy) 具有扩展功能,可以使此操作变得更容易:

下面是使用 JAXB 和 JPA 的一个模型的示例。 JPA 创建 RESTful 服务:

I agree that using the same model classes is the right approach. If you are concerned about annotation clutter, you could use a JAXB implementation (such as EclipseLink JAXB) that provides a mechanism for externalizing the metadata:

Also since you are using a JPA model EclipseLink JAXB (MOXy) has extensions for making this easier:

Here is an example of using one model with JAXB & JPA to create a RESTful service:

梦醒时光 2024-08-19 17:00:29

在同一个类上使用两个注解是没有问题的。我什至倾向于鼓励这样做,因为这样您就不必在发生更改时进行复制粘贴。
在某些情况下,某些属性的行为有所不同 - 例如,可能不需要对自动生成的 ID 进行编组。然后将 @XmlTransient@Transient 组合起来。它确实变得有点难以阅读,但也不是太难,因为所有注释的含义都很明显。

There is no problem in using both annotations on the same class. I even tend to encourage this, because thus you don't have to copy-paste when changes occur.
In some cases, some properties differ in behaviour - for example an auto-generated ID might not be required to be marshalled. @XmlTransient and @Transient are then combined. It does become a bit hard to read, but not too hard, because it is obvious what all the annotations mean.

秋凉 2024-08-19 17:00:29

有人试图将原子链接对象放入您的持久域中,因为您已承诺在那里定义您的 Web 服务 xml 结构?我觉得这样做很奇怪。 Hateoas 链接似乎是个好主意,但持久域和服务实现(不是 Web 服务)对原子链接不感兴趣。话又说回来,使用 xml 注释并让 jersey 为我序列化我的域当然很方便。不过,这种方法的另一个缺点是,通过持久域“层”重构,很容易在运行时影响 Web 服务使用者。

Anyone tempted to put atom link objects in your persisted domain because you have committed to defining your web service xml structure there? It seems strange to me to do this. Hateoas links seem like a good idea but the persisted domain and the service impl (not the web service) have no interest in atom links. Then again, using xml annotations and having jersey serialize my domain for me certainly is convenient. Another downside of this approach though is that it is to easy to impact your web service consumers at runtime with persistence domain "layer" refactoring.

你又不是我 2024-08-19 17:00:29

我知道这个问题有点老了,但我想无论如何我都会权衡一下,因为这是我最近遇到的一个问题。我的建议是保留 JAXB 带注释的类,因为任何模式更改都需要重新生成这些类。这意味着您必须手动重新输入任何休眠注释等。这可能是一个有点过时的解决方案,但我认为创建一个休眠映射文件(.hbm.xml)来容纳外部映射是完全合理的。在我看来,这更灵活,更简洁,而且同样有用。

I know this question is a bit old, but I thought I'd weigh in anyways since this is an issue that I've recently come across. My recommendation would be to leave your JAXB annotated classes alone, since any schema change will require re-generating these classes. Meaning you will have to re-enter any hibernate annotations, etc. manually. This may be a little out-dated solution, but I think it would be perfectly reasonable to create a hibernate mapping file (.hbm.xml) to house the mappings externally. This is a little more flexible, less cluttered, and just as useful in my opinion.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文