MEF 대 모든 IoC
Microsoft의 MEF (Managed Extensibility Framework)와 다양한 IoC 컨테이너 (예 : Unity)를 살펴보면 한 가지 유형의 솔루션을 다른 유형보다 사용해야 할 때를 알 수 없습니다. 보다 구체적으로 MEF는 대부분의 IoC 유형 패턴을 처리하고 Unity와 같은 IoC 컨테이너는 필요하지 않은 것 같습니다.
이상적으로는 MEF 대신 또는 MEF에 추가하여 IoC 컨테이너를 사용하는 좋은 사용 사례를보고 싶습니다.
요약하면 가장 큰 차이점은 IoC 컨테이너는 일반적으로 정적 종속성 (컴파일 시간에 알려짐)에 가장 유용하고 MEF는 일반적으로 동적 종속성 (런타임에만 알려짐)에 가장 유용하다는 것입니다.
따라서 둘 다 컴포지션 엔진이지만 강조점은 각 패턴마다 매우 다릅니다. 따라서 MEF는 알려진 부품의 등록이 아닌 알려지지 않은 부품의 발견을 중심으로 최적화되기 때문에 설계 결정은 매우 다양합니다.
이렇게 생각해보십시오. 전체 애플리케이션을 개발하는 경우 IoC 컨테이너가 가장 좋습니다. 타사 개발자가 시스템을 확장 할 수 있도록 확장 성을 위해 작성하는 경우 MEF가 가장 좋습니다.
또한 @Pavel Nikolov의 답변에있는 기사는 훌륭한 방향을 제공합니다 (MEF의 프로그램 관리자 인 Glenn Block이 작성했습니다).
저는 한동안 MEF를 사용해 왔으며 IOC 제품 대신 MEF를 사용할 때의 핵심 요소는 주어진 시간에 플러그인 디렉토리에 주어진 인터페이스의 3-5 개 구현을 정기적으로한다는 것입니다. 어떤 구현을 사용해야하는지 실제로는 런타임에만 결정할 수 있습니다.
MEF는 당신이 그렇게 할 수 있도록 잘합니다. 일반적으로 IOC는 원뿔형 예를 들어 ORM 제품 1을 기반으로하는 IUserRepository를 향후 언젠가 ORM 제품 2 용으로 교체 할 수 있도록 설계되었습니다. 그러나 대부분의 IOC 솔루션은 주어진 시간에 유효한 IUserRepository가 하나만 있다고 가정합니다.
그러나 주어진 페이지 요청에 대한 입력 데이터를 기반으로 하나를 선택해야하는 경우 IOC 컨테이너는 일반적으로 손실됩니다.
예를 들어, 제가 한동안 작업해온 큰 웹 앱에 대해 MEF 플러그인을 통해 권한 확인 및 유효성 검사를 수행합니다. MEF를 사용하여 레코드의 CreatedOn 날짜를 확인하고 레코드가 생성되었을 때 실제로 유효한 유효성 검사 플러그인을 찾고 해당 플러그인과 현재 유효한 유효성 검사기를 통해 레코드를 실행하고 레코드의 유효성을 비교할 수 있습니다. 시각.
이러한 종류의 힘은 또한 플러그인에 대한 폴 스루 오버라이드를 정의 할 수있게합니다. 제가 작업중인 앱은 실제로 30 개 이상의 구현을 위해 배포 된 동일한 코드베이스입니다. 따라서 우리는 일반적으로 다음을 요청하여 플러그인을 찾습니다.
- 현재 사이트 및 문제의 특정 레코드 유형에 특정한 인터페이스 구현입니다.
- 현재 사이트에 고유하지만 모든 종류의 레코드에서 작동하는 인터페이스 구현입니다.
- 모든 사이트 및 모든 레코드에서 작동하는 인터페이스입니다.
이를 통해 시작될 기본 플러그인 세트를 번들로 묶을 수 있지만 특정 구현이 고객 별 규칙으로 재정의하지 않는 경우에만 가능합니다.
IOC는 훌륭한 기술이지만 실제로는 구체적인 구현 대신 인터페이스에 쉽게 코딩 할 수 있도록 만드는 것입니다. 그러나 이러한 구현을 교체하는 것은 IOC의 프로젝트 전환 이벤트에 가깝습니다. MEF에서는 인터페이스와 구체적인 구현의 유연성을 활용하여 사용 가능한 여러 옵션 사이에서 런타임 결정을 내립니다.
주제를 벗어난 것에 대해 사과드립니다. MEF를 불필요한 합병증으로 만드는 두 가지 결함이 있다고 말하고 싶었습니다.
속성에 기반을두기 때문에 일이 작동하는 이유를 파악하는 데 도움이되지 않습니다. 정확히 무슨 일이 일어나고 있는지보기 위해 프레임 워크의 내부에 묻혀있는 세부 사항에 도달 할 방법이 없습니다. 추적 로그를 가져 오거나 해결 메커니즘에 연결하여 해결되지 않은 상황을 수동으로 처리 할 방법이 없습니다.
일부 부품이 거부되는 이유를 파악할 수있는 문제 해결 메커니즘이 없습니다. 실패한 부분을 지적 했음에도 불구하고 그 부분이 실패한 이유를 알려주지 않습니다.
그래서 매우 실망 스럽습니다. 나는 실제 문제를 해결하는 대신 몇 개의 수업을 부트 스트랩하기 위해 풍차와 싸우는 데 너무 많은 시간을 보냈습니다. VS 디버거에서 생성되는 내용과시기를 완전히 제어 할 수 있고 추적 할 수있는 경우 구식 종속성 주입 기술보다 더 좋은 것은 없다고 확신했습니다. MEF를 옹호하는 누군가가 내가 일반 DI보다 왜 그것을 선택해야하는지에 대해 많은 좋은 이유를 제시했으면합니다.
MEF가 완전한 기능을 갖춘 IoC 프레임 워크가 될 수 있다는 데 동의합니다. 사실 저는 확장 성과 IoC 모두를 위해 MEF를 사용하여 지금 애플리케이션을 작성하고 있습니다. 나는 그것의 일반적인 부분을 가져다가 "프레임 워크"로 만들고 사람들이 그것이 어떻게 작동하는지보고 싶어 할 경우를 대비하여 SoapBox Core 라는 자체 프레임 워크로 오픈 소스했습니다 .
특히 MEF가 작동하는 것을보고 싶다면 호스트 가 어떻게 작동 하는지 살펴보십시오 .
참고 URL : https://stackoverflow.com/questions/1288376/mef-vs-any-ioc
'Nice programing' 카테고리의 다른 글
| Jquery $ (this) 자식 선택기 (0) | 2020.11.11 |
|---|---|
| C에서 좋은 해시 테이블 구현을 찾고 (0) | 2020.11.11 |
| ORA-00972 식별자가 너무 긴 별칭 열 이름입니다. (0) | 2020.11.11 |
| 유사한 결과를 찾고 유사성을 기준으로 정렬하는 방법은 무엇입니까? (0) | 2020.11.11 |
| CDI는 Spring의 좋은 대체품입니까? (0) | 2020.11.11 |