OSGi与持久性的模块性：关系的影响

Question

围绕这篇文章标题的大多数问题都要求在OSGi容器中运行Hibernate或其他一些访问层。或者他们询问是否在OSGi容器中运行数据源。

我的问题涉及OSGi模块化对数据库本身结构的影响。具体做法是：

1. 我们如何使数据库本身的结构模块化，以便 当我们加载一个模块 - 比如联系人管理 - 模式是 更新为包括与该模块特别关联的表？
2. 上述方法对关系的影响是什么？

我认为第二个问题更有趣。假设联系人管理和项目管理是两个不同的OSGi模块。每个都在架构中有自己的一组表。但是，如果在数据库级别，我们需要在两个或更多表之间形成跨模块关系呢？也许我们希望看到某个联系人已经或正在进行的项目列表。

任何解决方案似乎都导致各个模块必须彼此了解太多的路径。我们可以写入项目管理规范，该模块期望联系人的来源，然后通过服务，接口，pub-sub等抽象出这样的期望。但是，似乎要做很多工作，以避免之间的硬连接关系两个模块的基础表。

如果我们可能需要通过下面的表之间的关系打破模块化，那么模块化在顶部和中间的重点是什么？非规范化和服务总线真的是一个健康的解决方案吗？

有什么想法吗？

谢谢。

Answer 1

关于第一个问题，可以使用LiquiBase。您可以在捆绑激活和停用时更新和回滚变更集。

关于第二个问题，我认为在设计架构时应该考虑这个问题。某些工具没有帮助。 如果PM模块依赖于CM模块，则PM模块可以安全地假设当前存在CM表并与它们建立外来关系，但不是相反的方向。您应该在架构中明确说明哪些模块取决于哪些模块并防止依赖循环。

Answer 2

经过5年的JPA，我决定离开它，经过数月的调查，我发现Querydsl + Liquibase组合最好。

我在开发帮助程序OSGi组件和maven-plugin方面做了很多工作。 maven-plugin（代码生成）的功能可以很容易地集成到其他构建工具中，因为maven插件只是一个独立库的包装。

您可以在此处找到有关解决方案的详细文章：http://bzsoldos.wordpress.com/2014/06/18/modularized-persistence/

Answer 3

在这种情况下，评估这些模块/上下文的独立性非常重要。在DDD术语中，这两个似乎是独立的有界上下文，因此pm模块中的联系人是与cm模块中的联系人不同的实体（以及另一个类）。如果你保持这种区别，那么接触实体会有一些非规范化（例如，在将其添加到项目时复制联系人的ID和名称，以后对cm模块中的联系人的更改将需要一些pubsub来保持一致性）但是每个模块都会非常独立。我会将ui作为一个单独的模块，取决于两者并提供必要的胶水（即传递它们之间的ID和所需信息）。

Answer 4

也许我误解了这个问题，但在我看来，OSGI模块化对数据库结构完全没有影响。它是一个数据存储级别，当然它可以是模块化的，但是由于它自己的原因 - 性能，数据量，负载等以及它自己的解决方案 - 集群，olap，分区和复制。

如果您需要cm和pm之间的数据完整性，则应该通过最初为此类任务设计的方法提供 - RDBMS。如果您需要软件模块化 - 您选择OSGI解决方案，您的模块正在更高的逻辑/业务级别进行通信。他们完全不知道如何提供持久性 - 纯文本文件或100节点Oracle RAC集群。