OSGi：我应该有一个 Dao 包吗？

Question

假设我有一个业务应用程序模块，例如用户管理（嗯）。 有两种捆绑设计方式（据我所知）。

A.datasource, um-model, um-dao, um-service, um-wab

B.datasource, um-api, um-impl

B是我现在更喜欢的。

我的一些考虑：

1. 根据“java 应用程序架构：模块化模式与使用 osgi 的示例”，我想要细粒度的粗粒度模块。 但是，方式 A 过于细粒度。道应该是私人的。如果另一个模块订房，会查询用户，它应该依赖于module(bundle) um-api。
2. 很少有人会设计模块（捆绑包）um-dao-api、um-dao-jpa-impl、um-dao-jdbc-impl、um-dao-jdo-impl。也许 um-api、um-ldap-impl、um-avos-delegate-impl 是更好的设计。
3. 数据源是一个模块（包），因为我想要应用模块之间的事务。

所以，我认为 Dao 不应该捆绑。

有什么想法吗？

谢谢！

Answer 1

虽然这里总是有一些品味问题，但我的经验是，以下可能是一个很好的起点：

• 通过将接口定义 (API) 与实现分开，将它们放在不同的包中。一个包只包含带有接口的包（可能还有一些非常基本的 POJO），实现放在不同包中的一个或多个其他包中。原因：由于实现经常发生变化，依赖关系往往会随着时间的推移变得更加复杂。将 API 包放在单独的包中可能会避免额外的维护工作。
• 为您的接口包和包之间的包中的包创建一个清晰的、解开的分层架构。原因：如果包的功能分离没有明确定义，在维护过程中可能会变得更加混乱。
• 如果您怀疑某些功能是否仅用于您的实现捆绑包或将来可能被其他功能使用，它可能会被其他人使用。但是，您始终可以决定在您的实现包中定义私有接口包，这些包将来可以很容易地移动到 API 包中。没有什么能阻止您在实现包中使用模块化架构，尽管有些人认为这没有必要，因为这部分在很大程度上对外界来说是不可见的（我不同意）。

在您的情况下：如果您不希望其他功能使用 DAO 的东西，请制作接口包并将其与实现一起放在实现包中，但不要导出包。如果您以后需要以某种方式导出它，请将接口包移动到 API 包。