我喜欢在Quarkus中使用JAX-RS的想法，因为它将使代码不依赖于框架实现。然而，当涉及到DB we're proposed时，使用“Panache”并从PanacheEntity扩展DB实体。我想这非常方便，对AOT工作很好（这基本上是 quarkus 正在尝试做的）并大大简化了 quarkus 的工作，但它引入了对特定实现的严重依赖性，因此我们不能使用纯JPA模块。
这与“干净的架构”相冲突，并使这种DB模块的测试变得复杂（如果可能的话）。假设我希望能够对基于Spring和Quarkus的应用模块使用相同的DB模块（仅使用纯JPA注解）。这迫使我复制代码或在设计纯度方面作弊。
是否有可能使用纯JPA注解来实现持久性，并可能使用插件（在编译期间修改代码）或使用不执行运行时字节码修改/使用反射的ORM框架来支付代价？有任何示例吗？
祝贺1.0的发布！干得好，Quarkus团队。
2条答案
按热度按时间cbeh67ev1#
Panache完全是可选的，您可以坚持使用普通JPA，如https://quarkus.io/guides/hibernate-orm中所述。
如果你能解释一下为什么你认为你必须使用Panache，我相信这对Quarkus团队来说会很有趣。
9njqaruj2#
首先，我完全同意。我觉得这与规范优先的理念背道而驰。
但我有一种感觉，这个想法是为了扩展Quarkus的React能力，他们已经承认目前只适用于REST资源。
如果您坚持使用JPA，我猜您将无法访问Mutuniy特性，这与使用Panache和Hibernate Reactive不同。