【问题标题】:multiple OSGi service instances and DS binding多个 OSGi 服务实例和 DS 绑定
【发布时间】:2012-03-11 09:55:56
【问题描述】:

我认为将 OSGi 服务 + DS 一起使用是正确的,但是,我真的很想滥用它。要么,要么它只是纯粹的真棒。 (两者都可以)。

让我们想象一下下面的应用程序:它是一个房屋数据库。我有两个界面,House 和 Window。假设我为每个可用至少有一个实现,配置为......好吧,作为需要配置来实例化的组件,并且为了创建新实例,我只需将此配置提供给正确的 pid。 (它既不是工厂组件,也不是服务工厂 - 正式名称是什么?这是 Neil 的出色 post about it)。

到目前为止一切顺利,这就像一个魅力。

房子就是这样,房子。有自己的地址,每个人都不一样,很容易通过他们的街道属性来识别。但是,windows 实例可以在房屋之间共享;它们的配置基本上是宽高。

现在,这些组件还可以在 0..n 基数配置中相互绑定(即使您不想住在没有窗户的房子里)。所以每个房子都有一个窗户列表,对于每种窗户类型,我们知道哪个房子有它(多对多关系)。

我的问题是,假设两所房子共享相同的三个窗户。我该如何描述呢?我觉得基于属性的过滤不够表达。我也觉得这可能不是让框架实例化我的对象的正确方法,但它非常方便。

想法?我是在滥用还是按预期使用它?

(我也可以使用 DS 来完成一半的工作:将房屋列表绑定到它所引用的 Window 实例引用,反之亦然,然后组件实例可以调用 registerWhatever() 函数目标实例 - 但我仍然需要以某种方式描述至少这一半。)

【问题讨论】:

    标签: java osgi declarative-services


    【解决方案1】:

    在这里很难弄清楚你在问什么,可能是因为 House/Window 抽象不起作用。显然,这不是您真正在做的事情...您只是想模糊或简化真实模型吗?我知道这样做是有正当理由的,但 House/Window 听起来更像是域类,而不是服务或组件。如果你真的在为数据库的每一行创建一个服务,那么我认为你在滥用服务的概念。

    【讨论】:

    • 我正在尝试简化此处的真实模型,但这与我实际尝试做的非常接近。你说得对,这有点像将域对象与服务混合,我可能会滥用它。因此,假设您想使用 OSGi 创建上述内部应用程序 - 您将如何构建该架构?
    • @Zoltan:如果不了解更多需求,也很难说。如果它是一个简单的 CRUD 应用程序,那么您可能有某种 HousePersister 组件,可以从 DataSource 服务加载/保存房屋域对象。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-03-11
    • 2010-11-09
    • 2013-12-27
    • 1970-01-01
    • 1970-01-01
    • 2014-05-15
    相关资源
    最近更新 更多