내가 틀렸다면 수정하십시오. 그러나 MEF는 자동 발견 및 자동 배선이 가능한 일련의 알려지지 않은 것들 (플러그인)을 관리하는 데 적합합니다. 미래의 프로젝트를 위해 우리는 애플리케이션의 알려진 부분을 명시 적으로 구성하기 위해 실제 IoC 컨테이너가 필요합니다 (MEF는 좋지 않습니다). 게다가 자동 발견 된 플러그인 (가능하면 속성없는 POCO)을 지원해야합니다. IoC 컨테이너가 /를 기본적으로 쉽게 지원할 수 있습니까? 그렇다면 에 Unity 및 StructureMap에서이 작업이 수행되는 방법에 대한 간단한 힌트를 제공 할 수 있습니까? 그것들은 우리가 현재 선호하는 두 가지입니다. 우리는 실제로 IoC 컨테이너 과 MEF에 대한 의존성을 피하고 싶습니다.플러그인 아키텍처 용 IoC 컨테이너 사용
MEF는 기존의 의미에서 IoC 컨테이너가 아니지만 컨트롤의 반전을 수행한다는 점에 유의해야합니다. 사실, 저는 MEF가 다른 어떤 것과 마찬가지로 IoC 컨테이너라고 말하면 동의하지 않을 것입니다. Unity와 MEF의 실제 차이점은 기본적으로 MEF는 명시 적 형식 확인을 통한 구성을 지원하고 구성을 통한 형식 검색을 지원한다는 것입니다. 그러나 MEFContrib 프로젝트에서 보았 듯이 MEF가 전통적인 IoC 컨테이너처럼 행동하는 것은 전적으로 가능합니다. MEF는 모듈 식 구성 요소 동작에 대한 훌륭한 기준을 제공하며 많은 복잡한 접목을 수행하며 설계 방식에 따라 더 많은 기능을 추가 할 수 있습니다. 예를 들어, 다른 IoC 컨테이너 나 서비스 위치 지정자를 기반으로하는 기존 코드베이스를 가지고 있다고 가정하면 ExportProvider을 연결하여 공급자를 Common Service Locator 프로젝트와 같은 서비스 위치 지정자에 연결 한 다음 호환 가능 CSL 구현을 지원하고 MEF가 다른 IoC 컨테이너에서 파생 된 유형을 사용하여 구성 요소 파트를 작성하게하십시오. MEF는 또한 의존성 주입을 수행합니다.
특정 IoC 컨테이너 나 MEF 자체에 의존하지 않으려면 일반적인 컨테이너 작업에 대한 추상화 인 공용 서비스 로케이터와 같은 것을 항상 사용할 수 있습니다. 그렇게하면 모든 것이 함께 연결되는 방식을 변경하거나 변경하고 싶을 때 상대적으로 어려워집니다. 대부분의 IoC 컨테이너 및 MEF에는 호환 가능한 CSL 구현이 있습니다.
희망이 있습니다.
MEF Contrib는 부품이 속성없이 POCO가 될 수 있습니까? – bitbonk
Attributed 모델은 MEF의 기본 프로그래밍 모델 일뿐입니다. MEFContrib는'ConventionCatalog'를 가지고 있는데, PartRegistry와 결합하면 Unity/Autofac/Windsor 등과 같은 컨테이너처럼 더 많은 타입을 등록 할 수 있습니다. –
MEF를 플러그인에 사용하는 것이 잘못된 이유는 무엇입니까? 이 사용 케이스와 .Net 프레임 워크의 일부분을 위해 정확하게 설계되었습니다. – jeroenh
Spring.Net을 살펴보십시오. –
당신은 IoC 컨테이너와 MEF를 피하기를 원했기 때문에 대답으로 게시하지 않을 것이라고하셨습니다. 그러나 [Autofac] (http://nblumhardt.com/2010/04/introducing-autofac-2-1-rtw/)는 MEF와 꽤 잘 통합되어 있습니다. –