OSGi 서비스 + DS를 함께 사용하면 제대로 된 것 같습니다. 그러나 실제로 악용하는 듯합니다. 어느 쪽이든, 그것은 단지 순수한 것입니다. (둘 다 가능합니다).여러 OSGi 서비스 인스턴스 및 DS 바인딩
다음 응용 프로그램을 가정 해 보겠습니다. 집 데이터베이스입니다. 두 개의 인터페이스 인 House와 Window가 있습니다. 사용할 수있는 각각의 구현을 적어도 하나 이상 가지고 있다고 가정 해 보겠습니다 ... 인스턴스화 할 구성이 필요한 구성 요소로 구성되고 새로운 인스턴스를 만들려면이 구성을 올바른 pid에 제공하면됩니다. (팩토리 팩토리도 아니고 서비스 팩토리도 아닙니다. 공식 이름은 무엇입니까? 여기 Neil의 post about it이 우수합니다.)
지금까지 그렇게 좋았습니다. 이것은 매력처럼 작동합니다.
주택은 바로 그것들입니다. 자신의 주소가 있으니, 각 하나는 다르며 거리 속성으로 쉽게 구분할 수 있습니다. 그러나 windows 인스턴스는 주택간에 공유 할 수 있습니다. 그들의 구성은 기본적으로 너비와 높이입니다.
이제는 이러한 구성 요소가 0..n 카디널리티 구성에서 서로 바인딩 될 수도 있습니다 (창없는 집에 살고 싶지 않더라도). 따라서 각 집에는 창 목록이 있으며, 각 창 유형에 대해 어느 하우스가 있는지를 알 수 있습니다 (다 대다 관계).
내 문제는 두 집이 같은 세 개의 창을 공유한다고 가정 해 봅시다. 어떻게 설명 할 수 있습니까? 속성 기반 필터링은 표현력이 충분하지 않다고 느낍니다. 또한 프레임 워크에서 객체를 인스턴스화하는 올바른 방법이 아닌 것처럼 느껴질 수도 있지만 너무 편리합니다.
생각하십니까? 내가 학대를하거나 의도 한대로 사용하고 있습니까?
(전 작업의 절반 만 얻으려면 DS를 사용할 수도 있습니다. 하우스 목록을 Window 인스턴스 참조에 바인드하거나 그 반대로 바인딩 한 다음 구성 요소 인스턴스가 registerWhatever() 함수를 호출 할 수 있습니다. 그러나 적어도이 절반은 어떻게 든 설명해야합니다.)
여기 실제 모델을 단순화하려고 노력하고 있지만 실제로 시도하고있는 것과 거의 같습니다. 당신은 도메인 객체를 서비스와 혼합하는 것이고, 가능하다면 그것을 악용 할 수도 있습니다. OSGi를 사용하여 위의 집 애플리케이션을 만들고 싶습니다. 아키텍처를 어떻게 구축할까요? – Zoltan
@ Zoltan : 요구 사항에 대해 더 알지 못해도 말하기 어렵습니다. 간단한 CRUD 응용 프로그램이라면 DataSource 서비스에서 하우스 도메인 객체를로드/저장하는 일종의 HousePersister 구성 요소가있을 수 있습니다. –