服务模型与Extender模型？

作者: 哎？小查查
发布时间: 2025-02-05 02:46:29 (19天前)
转自：

3 条回复

0#
回复此人
清月 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 服务更常用，它们通常应该是您的首选，除非您有令人信服的理由设计新的扩展器。 OSGi是一个面向服务的平台。服务API在双方，消费者和提供者之间形成合同。合同是根据包含接口的Java包定义的，提供者通过实现这些接口来提供它。使用者使用服务注册表来查找要使用的接口的实例。 扩展器模式更灵活，更抽象，但理解和使用更复杂。从本质上讲，扩展程序包提供了额外的功能 代表 一些其他捆绑包，通常通过包含某种声明来选择。 例如，假设您要为应用程序实现帮助系统。 Bundles可以在一些商定的路径下简单地包含HTML文档，并且中央帮助系统包可以扫描包以查找这些文档并将它们添加到主帮助索引中。使用服务执行此操作会非常麻烦：假设您遵循“白板”样式，则必须定义一个 <code> HelpProvider </code> 用Java接口 <code> getHelpDocuments() </code> 方法;每个希望提供帮助的软件包都必须实现此接口并将其注册为服务。另一方面，帮助系统扩展器捆绑包需要相对智能，因为它必须跟踪来来往往的捆绑包。但至少你只需编写一次这个智能代码。 扩展器的现实例子如下： <UL> <LI> 声明性服务是一个寻找的扩展器 <code> Service-Component </code> 在其他捆绑中声明并代表他们做各种事情，以实例化组件，发布服务等。 </LI> <LI> 蓝图是一种类似的扩展器。它寻找 <code> Bundle-Blueprint </code> 声明或在商定路径下的XML文件。 </LI> <LI> OSGi企业规范定义了一个JPA扩展器，用于查找包含a的bundle <code> persistence.xml </code> 由...声明的文件 <code> Meta-Persistence </code> 头。当它找到一个时，它会为该包创建一个持久性单元。 </LI> <LI> Eclipse包含一个扩展器（混淆地称为扩展注册表），用于创建视图，透视图，菜单等内容。这些都是在 <code> plugin.xml </code> 文件在一个包的根目录中。 </LI> </UL> 总结一下......服务用于根据合同注册和查找对象。扩展器用于扩展bundle的功能，通常基于某种声明性资源或头而不是可执行代码。 </DIV>

编辑
1#
回复此人
易米烊光 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 扩展器模型主要用于框架。它需要深入研究bundle impl来完成它的工作。所以松耦合不好。优点是它可以定义一个全新的抽象，如蓝图或声明性服务或cdi。所有这些框架都使用扩展器模型根据规范连接您的捆绑包。 服务模型对您的应用程序本身是正确的。服务允许隐藏实现的细节以及服务用户的实例化。所以这对于松散耦合非常有用。 最后两者通常一起使用。例如，您可以使用cdi注释来连接您的捆绑包，并指定您提供和使用服务。因此，当您使用服务模型松散地连接捆绑包时，cdi框架会利用扩展程序在内部连接捆绑包。 </DIV>

编辑

登录后才能参与评论