OSGi：我应该有Dao捆绑吗？

Question

说我有一个业务应用程序模块，比如用户管理（嗯）。 有两种捆绑设计方式（我可以说）。

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

B.datasource，um-api，um-impl

B是我现在更喜欢的。

我采取的一些考虑因素：

1. 根据“java应用程序架构：使用osgi的示例模块化模式”，我想要细粒度的粗粒度模块。 但是，方式A太精细了。道应该是私人的。如果另一个模块房间预订，将查询用户，它应该依赖于模块（捆绑）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. datasource是一个模块（包），因为我想在app-modules之间进行交易。

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

任何想法？

THX！

Answer 1

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

• 将接口定义（API）与实现分开，将它们放在不同的包中。一个包只包含带有接口的包（可能还有一些非常基本的POJO），实现被放在不同包中的一个或多个其他包中。原因：由于实施经常发生变化，因此随着时间的推移，依赖性会变得更加复杂。将API包放在单独的包中可能会妨碍额外的维护工作。
• 为接口捆绑包和捆绑包中的捆绑包制作一个清晰的未解决的分层体系结构。原因：如果没有明确定义包装上的功能分离，则在维护过程中可能会变得更加混乱。
• 如果您怀疑某些功能是否仅用于您的实施包的私有用途，或者将来可能被其他功能使用，则可能最终被其他人使用。但是，您始终可以决定在实现包中定义私有接口包，以便将来可以轻松地将其移动到API包中。没有什么能阻止您在实现包中使用模块化体系结构，尽管有些人认为这不是必需的，因为这部分对外界来说基本上是不可见的（我不同意）。

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