2011-01-14 2 views
0

MEF를 구현하는 Windows 서비스를 작성하는 중입니다. 서비스는 하위 구성 요소를 관리하고 플러그 가능해야하며 전체 서비스 재 컴파일 및 배포 시나리오를 거치지 않고 런타임에 새로운 구성 요소를 도입 할 수 있어야합니다. 구성 요소는 플러그 가능해야합니다. 즉, 출력 어셈블리를 디스크의 지정된 폴더에 놓으면 Windows 서비스에서 "이봐, 여기에 새로운 구성 요소가 있습니다 ..."라고 말하면서 그냥 그 일을해야합니다. 그것이 MEF의 힘입니다. 지금까지는 아주 멋진 것들.Microsoft 확장 성 프레임 워크 - MEF CompositionContainer

사용 가능한 모든 하위 구성 요소 (어셈블리)를 가져 오기 위해 AggregateCatalog 및 CompositionContainer를 만드는 개념을 이해합니다. 이것은 모두 훌륭하며 Windows 서비스가 처음 시작될 때 예상대로 작동합니다. 그러나 결국에는 런타임에 새로운 구성 요소를 도입 할 예정이므로 어떤 시점에서는 추가 된 새로운 출력 어셈블리를 인식하기 위해 CompositionContainer가 필요합니다.

다음 내용에 대한 우려는 성능에 미치는 영향입니다. 이 효율적/안전 다음과 같은 루프로 CompositionContainer 로직 넣어된다

 [ImportMany(AllowRecomposition = true)] 
     private IEnumerable<Lazy<IMySubComponentTask, IDictionary<string, object>>>       
     MySubComponentTasks { get; set; } 

     while (true) 
     { 
      //Create a general aggregate catalog 
      var catalog = new AggregateCatalog(); 

      //Adds all the parts found in the same assembly as the Program class 
      catalog.Catalogs.Add(new AssemblyCatalog(typeof(MySubComponentTaskFactory).Assembly)); 

      //Create a new directory catalog 
      var directoryCatalog = new DirectoryCatalog(@".\Extensions"); 

      //Add the DLLs in the directory to the aggregate catalog 
      catalog.Catalogs.Add(directoryCatalog); 

      //Create the current composition container to create the parts 
      var container = new CompositionContainer(catalog); 

      //Fill the imports of this object 
      try 
      { 
      container.ComposeParts(this); 
      } 
      catch (CompositionException compositionException) 
      { 
      Console.WriteLine(compositionException.ToString()); 
      } 
     } 

의견이나 입력이 이해된다.

덕분에, 마이크

답변

1

아니, 나는 루프에 카탈로그 인스턴스를 넣어하지 않을 것입니다. 그러나 System.Timers.Timer 또는 System.Threading.Timer 일 경우 주기적으로 플러그인 디렉토리를 확인하는 것이 가장 좋습니다. 당신의 ImportMany 이후

는 재구성이 런타임에 새로운 조성를 추가 할 수 있어야합니다 수 있습니다 : Recomposition and constructors

+0

감사합니다. 아마도 그 길로 향할 것입니다. 여기에는 또 다른 것이 있는데, 간결함을 위해 위에서 언급하지 않았습니다. CompositionContainer가 시간 초과 조회마다 발견하는 각 하위 구성 요소에 대해 하위 구성 요소 작업을 별도의 스레드로 보냅니다. 새 스레드의 양을 관리하려면 이전 시간 초과 조회에서 발견 된 하위 구성 요소 작업을 이미 실행중인 스레드가 있는지 확인해야합니다. 스레드를 사용하여 얻은 경험은 무엇이며 스레드의 수는 너무 많습니까? 어떤 점에서, 나는이 것을 위해 15+ 하위 구성 요소를 가질 수있다. –

+0

@ 마이클 : 최대 스레드 수는 CPU와 코어 아키텍처에 달려있다. 구성 요소 스레딩을 관리하기 위해 작업 병렬 라이브러리를 참조합니다. – IAbstract

0

만들기 CompositionContainers 저렴해야한다 :

Timer checkPlugin = new Timer(); 

//set CheckForPlugins as a timer callback or action 
void CheckForPlugins() 
{ 
    // add plugins catalog if found in directory 
} 

내가 몇 가지 추가 정보를 발견했다. 조립품을 검사하여 MEF 부품을 찾아야하기 때문에 카탈로그를 만드는 것이 그렇게 저렴하지는 않습니다. 가능한 경우 루프 외부에서 카탈로그를 작성해야합니다.