不严重依赖 Panache 的 Quarkus？

Question

我喜欢在 Quarkus 中使用 JAX-RS 的想法，因为它将使代码不依赖于框架实现。 但是，当涉及到数据库时，我们建议使用“Panache”并从PanacheEntity扩展数据库实体。 我想这对 AOT 工作（基本上是 Quarkus 试图做的）非常方便和有益，并且大大简化了 Quarkus 的工作，但它引入了对特定实现的严重依赖，因此我们不能使用纯 JPA 模块。

这与“干净的架构”相冲突，并使此类 DB 模块的测试变得复杂 [如果可能的话]。 假设我希望能够对 Spring 和基于 Quarkus 的应用程序模块使用相同的数据库模块（仅使用纯 JPA 注释）。 它迫使我复制代码或在设计纯度方面作弊。

是否有可能使用纯 JPA 注释来实现持久性并可能使用插件（在编译期间修改代码）或使用不进行运行时字节码修改/使用反射的 ORM 框架来付出代价？ 有什么例子吗？

附言。 祝贺1.0发布，干得好。 夸克团队。

Answer 1

Panache 完全是可选的，您可以坚持使用普通的 JPA，如https://quarkus.io/guides/hibernate-orm中所述。

如果你能解释为什么你认为你必须使用 Panache，我相信这对 Quarkus 团队来说会很有趣。

Answer 2

首先，我完全同意。 我觉得这违背了规范优先的想法。

但我觉得这个想法是扩展他们已经承认的 Quarkus 反应能力，目前仅适用于 REST 资源。

如果您坚持使用 JPA，我猜您将无法访问 Mutuniy 功能，这与您使用 Panache 和 Hibernate Reactive 不同。