MEF (Managed Extensibility Framework) 대 IoC / DI

MEF (Managed Extensibility Framework) 대 IoC / DI

---

MEF (Managed Extensibility Framework)가 기존 IoC / DI 컨테이너로 해결할 수없는 문제는 무엇입니까?

---

MEF의 기본 목적은 확장 성입니다. 애플리케이션 작성자와 플러그인 ( 확장자 ) 작성자 가 다르고 게시 된 인터페이스 ( 계약 ) 라이브러리를 넘어서 서로에 대한 특별한 지식이없는 경우 '플러그인'프레임 워크 역할을합니다 .

MEF의 또 다른 문제 공간 MEF는 일반적인 IoC 의심과 다른 점을 다루며 MEF의 강점 중 하나는 [확장] 검색입니다. 확장과 연결할 수있는 메타 데이터에서 작동하는 확장 가능한 검색 메커니즘이 많이 있습니다. MEF CodePlex 사이트에서 :

"MEF는 풍부한 쿼리 및 필터링을 용이하게하는 추가 메타 데이터로 확장 태그 지정을 허용합니다."

태그 된 확장을 지연로드하는 기능과 결합하여로드 하기 전에 확장 메타 데이터를 조사 할 수 있는 것은 수많은 흥미로운 시나리오에 대한 문을 열어주고 [플러그인] 버전 관리와 같은 기능을 실질적으로 활성화합니다.

MEF에는 또한 확장이 '조정'또는 '변환'( 유형>에서 유형으로 ) 을 허용하는 '계약 어댑터'가 있으며 이러한 변환의 세부 사항을 완벽하게 제어 할 수 있습니다. 계약 어댑터는 '발견'이 의미하고 수반하는 것과 관련된 또 다른 창의적인면을 열어줍니다.

다시 말하지만, MEF의 '의도'는 익명의 플러그인 확장성에 매우 중점을두고 있으며 이는 다른 IoC 컨테이너와 매우 차별화됩니다. 따라서 MEF를 구성에 사용할 수 있지만 이는 다른 IoC에 비해 기능의 작은 교차점 일 뿐이며 앞으로 많은 근친상간 상호 작용을 보게 될 것입니다.

---

IoC 컨테이너는 여러분이 아는 것들에 초점을 맞 춥니 다. 즉, 단위 테스트에서 하나의 로거를 사용하고 내 앱에서 다른 로거를 사용할 것임을 알고 있습니다. MEF는 당신이하지 않는 것들에 초점을 맞추고 있으며, 내 시스템에 나타날 수있는 1에서 n 개의 로거가 있습니다.

---

Scott Hanselman과 저는 최근의 hanselminutes에서이 주제를 더 자세히 다루었습니다.

http://www.hanselminutes.com/default.aspx?showID=166

참조 URL : https://stackoverflow.com/questions/108116/mef-managed-extensibility-framework-vs-ioc-di