2

在 OSGI 应用程序上，是否可以将应用程序 Pojos 放在 Bundle 中并通过它访问它们？我的意思是只为应用程序 pojos 提供一个 Bundle 是一种很好的技术吗？

4

4 回答 4

1

想想一个场景，你的 pojo 包无法加载，因为说任何 XYZ 原因。这不意味着所有依赖的捆绑包/功能都会失败吗？

OSGi 用于使事物模块化，据我所知，模块是一段代码，它可以单独做一件事情，或者说具有最少的依赖性。

于 2013-05-28T17:39:37.457 回答
1

POJO 的意思是“普通的旧 Java 对象”，所以您似乎在说所有普通的 Java 对象都应该放在一个包中。这是否意味着所有“非普通”Java 对象都应该在其他包中？

这听起来不像是模块化应用程序的好标准。一个模块应该执行一些特定的逻辑功能，因此捆绑包中的所有类都应该与执行该功能相关。根据它们是“普通”还是“非普通”将类分成包是没有意义的，无论这意味着什么。

于 2013-05-28T23:20:34.240 回答
1

在模块化中，您希望优化内聚，这应该导致最小的耦合。凝聚力意味着“相互关联”。java.util 是内聚不好的一个很好的例子，因为需要 aCollection的人不一定需要 a Runnable(Util 包或库是可怕内聚的主要例子，因为它们聚集在一起的唯一原因是因为作者通常认为模块会太慢了）。

如果你把东西放在一起（聚合），你也会聚合它们的传递依赖。例如，如果您使用 Spring 的一小部分，它通常会拖入整个 spring。如果您正在制作一个依赖于 spring 的应用程序，那么这不是一个严重的问题。耦合后，实际上最好最大限度地使用该耦合。

然而 ...

构建大型应用程序最好从可以在不同应用程序之间独立设计、测试和重用的较小模块中完成。设计这些可​​重用模块的技巧是限制它们的依赖关系，以便应用程序不受这些（传递）依赖关系的约束。

那么你应该把 POJO 放在一个单独的包中吗？如果它们与应用程序耦合并且不可重用，则只需将它们与应用程序放在一起。如果你有可重复使用的部分，那么将这些可重复使用的部分放在单独的模块中。它们是否是 POJO 的事实有点无关紧要，这是您想要实现的最小耦合。

于 2013-05-29T16:51:31.250 回答
0

我认为如果 POJO 将被大量用于捆绑包，那么为 POJO 提供单独的捆绑包是个好主意。确实，如果此捆绑包失败，它将导致依赖它的其他捆绑包也失败。但这是一种理想的行为，因为 pojo 包在正常情况下不应该失败，因为它不应该具有按照定义的业务逻辑。如果它失败了，那应该表明有严重的错误，这值得你注意。

将 pojo 与应用程序逻辑打包在同一个包中也意味着您将分发大量只需要访问 pojo 的代码。

于 2013-05-28T21:00:30.357 回答