OSGi サービスと DS を一緒に使用して正しい軌道に乗っていると思いますが、それを悪用する気がします。それか、純粋に素晴らしいかのどちらかです。（両方ともまだ可能です）。
それでは、次のアプリケーションを想像してみましょう。これは家のデータベースです。House と Window の 2 つのインターフェイスがあります。インスタンス化する構成が必要なコンポーネントとして構成された、利用可能なそれぞれに少なくとも 1 つの実装があるとしましょう。新しいインスタンスを作成するには、この構成を適切な pid に提供するだけです。(これはファクトリ コンポーネントでもサービス ファクトリでもありません。正式名称は何ですか? Neil による優れた投稿があります)。
これまでのところ、これは魅力のように機能します。
家はまさにそれ、家です。独自の住所を持ち、それぞれが異なり、通りのプロパティで簡単に識別できます。ただし、windows インスタンスは家の間で共有できます。それらの構成は基本的に幅と高さです。
現在、これらのコンポーネントは、0..n カーディナリティ構成で相互にバインドすることもできます (窓のない家に住みたくない場合でも)。したがって、各家には窓のリストがあり、窓の種類ごとに、どの家にそれがあるかがわかります (多対多の関係)。
私の問題は、2 つの家が同じ 3 つの窓を共有しているとしましょう。これをどのように説明できますか？プロパティベースのフィルタリングは表現力が足りないように感じます。また、これはフレームワークにオブジェクトをインスタンス化させる正しい方法ではないかもしれないと感じていますが、とても便利です。
考え？悪用していますか、それとも意図したとおりに使用していますか?
(DS を使用して、仕事の半分を完了することもできます。Houses のリストを Window インスタンス参照にバインドするか、またはその逆にバインドすると、コンポーネント インスタンスはターゲット インスタンスで registerWhatever() 関数を呼び出すことができます。 -しかし、少なくともこの半分については、どうにかして説明する必要があります。)