我看到了许多关于OSGi的演示,我认为执行更好的模块化听起来很有希望。显然,“热部署”和“并行运行x的不同版本”也是市长的卖点。
我想知道OSGi promise 解决的问题是否甚至是一个问题...?这让我想起了OO的早期,当时提出了类似的要求:
当OO 是新的时,最大的争论是可重用性。人们普遍认为,使用OO时,只需要“写一次”就可以“随处使用”。
在实践中,我只看到了一些非常简单的示例。我认为这样做的原因是很难编写可重用的代码。从接口(interface)设计的角度来看,这不是技术上的,而是技术上的。您必须预期 future 的客户将如何使用您的类(class)并预先做出正确的选择。从定义上讲,这很困难,因此潜在的可重用性 yield 通常无法实现。
使用OSGi ,我怀疑在这里我们可能会再次兑现 promise ,为我们实际上没有的问题提供潜在的解决方案。或者,如果我们拥有它们,我们就没有足够数量和严重程度的东西,不足以使他们有理由向OSGi购买帮助。例如,将“热部署”作为模块的子集绝对是一个好主意,但是它真正能够工作多久?多久一次,不是因为您发现特定问题的模块化错误?在多个模块之间共享的模型实体怎么样?这些模块都必须同时更改吗?还是将对象展平为基元并仅在模块间通信中使用那些对象,以便能够保留接口(interface)协定?
我认为,应用OSGi时最困难的问题是以获得模块化“正确”的。与使用OSGi在OO中正确设置类的接口(interface)类似,这次问题在更大的范围,包甚至服务级别上都保持不变。
您可能已经猜到了,我目前正在尝试评估OSGi在项目中的使用情况。我们面临的主要问题是,随着代码库的增长,复杂性也在增加,我想将系统分解为具有越来越少定义的交互的较小模块。
谢谢!
最佳答案
OSGi之所以获得返回,是因为它在运行时强制执行了模块化,而这是您以前所没有的,通常会导致纸上的设计和实现偏离。在开发过程中,这可能是一个巨大的胜利。
如果您让团队将精力集中在单个模块(可能是一组 bundle 软件)上,并且正确实现了模块化,那么它无疑将使团队工作变得更容易。有人可能会说,使用Ant + Ivy或Maven这样的构建工具和依赖项可以完成相同的工作,我认为OSGi所使用的依赖项的粒度要优越得多,不会造成典型的“拖累所有事物以及厨房水槽” JAR级别依赖性引起的。
具有较少依赖关系的模块化代码往往会导致代码更简洁,更少,从而导致更少的错误,这些错误更易于测试和解决。它还促进了设计尽可能简单明了的组件,同时可以选择插入更复杂的实现,或添加诸如缓存等功能作为单独的组件。
即使您在运行时不使用热部署,热部署也是一个很好的测试,可以验证是否正确地模块化了应用程序。如果根本无法随意启动 bundle 包,则应调查原因。此外,如果您可以更新任意 bundle 包,则可以使您的开发周期更快。
只要您可以管理模块和依赖项,大型项目就可以保持可管理性,并且可以轻松地进行开发(从可以说是糟糕的“完全重写”中解脱出来)。
OSGi的缺点?这是一个非常低级的框架,虽然可以很好地解决预期的问题,但您仍然需要解决一些问题。特别是如果您来自Java EE环境,在那里您可以获得免费的线程安全性以及一些其他必要的概念,这些概念在需要时可能非常有用,那么您需要自己在OSGi中提出解决方案。
一个常见的陷阱是不要在OSGi上使用抽象来使普通开发人员更容易做到这一点。永远不要让他们手动与ServiceListeners或ServiceTrackers混为一谈。仔细考虑什么是 bundle 包,哪些 bundle 包是不允许使用的:您是否愿意让开发人员访问BundleContext,还是通过使用某种形式的声明性模型将所有 bundle 包隐藏起来。