使用JPA时的标准工作流程

时间:2010-05-27 03:44:09

标签: java jpa workflow

我目前正在尝试与JPA合作。我情不自禁地觉得我错过了一些东西,或者做错了。到目前为止,这似乎是被迫的。

到目前为止,我认为我知道他们有几种方法可以使用JPA和工具来支持这一点。

  • 您可以使用注释在Java中执行所有操作,并让JPA(您决定使用的任何实现)创建架构并在进行更改时更新它。
  • 您可以使用工具对数据库进行反向工程,并为您生成实体类。更新架构时,您必须重新生成这些类,或手动更新它们。

这两者似乎都有缺点,并且两者都有好处(就像所有事情一样)。 我的问题是在理想的情况下,JPA的标准工作流程是什么?大多数模式在维护阶段需要更新,特别是在开发阶段,所以如何处理?

3 个答案:

答案 0 :(得分:1)

像往常一样,答案取决于......

理想方法(在理想世界中)可能是您的第一选择:使用实用工具(例如使用Hibernate Maven plugin)使用JPA注释和转发工程师数据库工件来维护所有内容。

这取决于对数据库工件的支持级别 - 并非所有内容都属于或适用于注释。这就是为什么我的项目通常对两者都使用并行维护并使用单元测试来保持它们同步。

它还取决于可用资源。如果您有一位负责数据库的专职DBA,那么将维护委托给她是有意义的。

其他考虑因素是在JPA中实际完成了多少数据库开发。是否存在使用相同后端的存储过程或其他非JPA应用程序,或者您只是与其他团队的数据库集成...

答案 1 :(得分:1)

从带注释的实体生成数据库模式并不总是一种好方法。虽然理论上听起来很棒 - 但实际上生成的模式通常不是最优的,也不会满足并经历过DBA。

我在工作流程中遵循的方法是分别创建实体和数据库模式,同时仍然使用非常智能的工具来创建模式 - 像Liquibase这样的数据库无关,支持修订, rollbacks等...或者一个自定义的烘焙迁移工具,它只运行大量优化的特定于db的sql脚本。

这可能听起来不太理想,但我可以保证它可以完成工作并保持与模式相关的代码一致,因为正如格里戈里所指出的那样 - 并非所有与数据库相关的内容都可以从实体生成。 / p> 但是,对于从运行单元和集成测试的测试数据库的实体生成模式,我可以很有用。假设你正在使用说PostgreSQL是生产你可能决定加速运行一些嵌入式内存数据库(如H2)的单元测试,它在测试开始之前从实体创建并自动消失(因为它在内存中) )测试完成后执行。这是一种非常普遍的做法。

答案 2 :(得分:1)

如果这是一个现有的应用程序,我会检查你现有的内容,如果数据库结构复杂,可以看到DDL和DDL显示数据库本身正在进行重要的逻辑,那么你最好使用纯SQL,让DBA维护您的数据结构。当数据库结构已经很复杂并且在那时使用JPA没有商业利益时,JPA并没有真正发挥作用。

需要发生的是迁移到JPA的项目。这有一些好处:

  • 将业务逻辑从数据库层(更难以横向扩展)移除到应用程序层。
  • 与DBA相比,Java开发人员通常更便宜。虽然你仍然需要能够同时做数据库思维和Java思维的人才能做到这一点并且这种做法更为罕见。
  • 通过将数据库缩减为简单的数据存储区,您可以摆脱供应商锁定。
  • 如果操作正确,您可以拥有一个不同的数据库进行开发(可以是免费的DB2 Express C),并为您的集成和生产环境(例如,zOS的DB / 2)提供更强大的数据库。这使您能够拥有更多开发人员,而无需担心许可成本。

对于正在生成的模式等,实际上可能会发生四种工作流程:

  1. 对于设计,对象关系(而不是实体 - 关系)图表用作应用程序团队和数据库团队之间的契约。最终结果是JPA对象将在DBA设置的物理数据结构中运行。
  2. 对于Java应用程序开发,只需让每个开发人员拥有自己的数据库,让他们尽可能多地将其炸毁。 JPA代码将为您生成模式。
  3. 对于数据库开发,生成的模式和类图将由DBA传递给审查,以查看可以改进性能的位置。具体而言,它们用于指定JPA标准中不可用的索引,因为它不是跨数据库。它们也可用于设置表空间以及开发的所有访问控制和模式,但至少可以将结构的要点从它们中删除并传递给应用程序团队,这使应用程序团队可以更灵活地适应改变。通常会发生的事情是DBA只包含一些生成的SQL,然后更改添加其他列以及其他用于应用程序之外的其他目的的列(JPA结构只需要应用程序所需的内容,它不需要将100%一对一映射到数据库)
  4. 对于迁移,DBA需要在两个模式之间进行差异分析。有一个名为dbsolo(非免费)的程序可以用于大多数数据库。但是,如果事情是在JPA中完成的,那么结构就更简单了,因为理论上数据库上不再存在任何业务逻辑,从而降低了升级导致的数据迁移的复杂性。
  5. 它的网络是你不能只说你在使用JPA而不涉及整个交付团队,这将需要包括DBA愿意放弃对应用团队的数据结构的控制和所有权,但是仍然是设计和评论的一部分。