MEF와 MAF 선택 (System.AddIn)


162

MEF (Managed Extensibility Framework)와 MAF (일명 System.AddIn)는 매우 유사한 작업을 수행하는 것으로 보입니다. 이 스택 오버플로 질문에 따르면 MEF는 System.Addin을 대체합니까? 동시에 두 가지를 모두 사용할 수도 있습니다.

언제 하나를 사용하겠습니까? 어떤 상황에서 두 가지를 함께 사용 하시겠습니까?

답변:


131

나는 이러한 옵션을 평가 해 왔으며 여기에 내가 온 결론이 있습니다.

MAF는 진정한 애드온 프레임 워크입니다. 애드온이 완전히 분리되어 별도의 앱 도메인 내에서 실행 되어도 애드온이 충돌하더라도 응용 프로그램이 중단되지 않도록 할 수 있습니다. 또한 계약서 외에는 애드온을 분리하는 매우 완벽한 방법을 제공합니다. 실제로 기본 앱을 업그레이드하는 동안 계약 어댑터를 버전 화하여 이전 애드온과의 호환성을 제공 할 수 있습니다. 이것은 훌륭하게 들리지만 앱 도메인을 교차하기 위해 지불 해야하는 많은 비용이 따릅니다. 이 가격을 신속하고 유연하게주고받을 수있는 유형으로 지불합니다.

MEF는 검색 가능성 및 ... (이 항목에 공백 그리기)과 같은 몇 가지 추가 이점이있는 종속성 주입과 비슷합니다. MAF가 갖는 분리 정도는 MEF에 존재하지 않습니다. 그것들은 두 가지 다른 것을위한 두 가지 다른 프레임 워크입니다.


5
한 가지 작은 점 : 애드온이 기본 계층에서 충돌하는 경우 '별도의 appdomain'이 도움이되지 않으므로 작업자 프로세스가 여전히 필요하다는 것을 기억하십시오. MAF는 매우 하드 (하지만 가능) 여전히를 생성하지만, 동적으로 충돌 복구에 다소 도움이
케찰코아틀이

@ Ian : 내 의견을 다시 읽어주십시오.) 정확하게 작성했습니다. 더보기 : MAF는 실제로 허용하지만 충돌 후 혼자서 일어나야합니다.
quetzalcoatl

@DanielG> 앱 도메인을 교차시키기 위해 지불해야하는 가격이 많이 듭니다. <이 이유는 무엇입니까? 얼마나 무거운 지'?
Martin Meeser

2
@MartinMeeser 앱 도메인을 교차 할 때는 모든 것을 직렬화하거나 MarshalByRef 객체를 사용해야합니다. 통신은 동일한 앱 도메인에서 객체 간 대화보다 훨씬 어렵습니다.
Danielg

65

Danielg가 말한 것이 좋습니다. 나는 추가 할 것이다 :

System.Addins에 대한 비디오를 보면 매우 큰 프로젝트에 대해 분명히 이야기하고 있습니다. 그는 일 개에 대해 이야기 팀이 호스트 응용 프로그램, 다른 관리 각 추가 기능 관리, 제 3 계약과 파이프 라인을 관리합니다. 이를 바탕으로 System.Addins은 더 큰 응용 프로그램을위한 것이라고 생각합니다. SAP와 같은 ERP 시스템과 같은 응용 프로그램을 생각하고 있습니다 (큰 것은 아니지만 아이디어를 얻습니다). 해당 비디오를 본 경우 System.Addins를 사용하는 작업량이 매우 많다는 것을 알 수 있습니다. 시스템에 타사 애드 인을 프로그래밍하는 회사가 많고 사형에 처한 애드 인 계약을 위반할 수없는 경우에는 잘 작동합니다.

반면에 MEF는 SharpDevelop의 추가 기능 체계, Eclipse 플러그인 아키텍처 또는 Mono.Addins와 더 유사합니다. System.Addins보다 이해하기가 훨씬 쉽고 훨씬 유연합니다. 잃어버린 것은 MEF와 함께 즉시 사용 가능한 AppDomain 격리 또는 강력한 버전 관리 계약을 얻지 못한다는 것입니다. MEF의 강점은 전체 응용 프로그램을 부품 구성으로 구성 할 수 있으므로 고객마다 다른 구성으로 제품을 배송 할 수 있으며 고객이 새로운 기능을 구매하는 경우 해당 기능에 대한 부품을 설치 디렉토리에 놓기 만하면됩니다 응용 프로그램에서이를보고 실행합니다. 또한 테스트를 용이하게합니다. 테스트하려는 객체를 인스턴스화하고 모든 의존성에 대해 모의 객체를 제공 할 수 있습니다.

내가 언급하고 싶은 가장 중요한 점은 System.Addins가 이미 프레임 워크에 있지만 그것을 사용하는 사람들에 대한 많은 증거를 보지 못하지만 MEF는 CodePlex에 포함되어있을 것입니다. .NET 4 및 사람들은 이미 자체 응용 프로그램을 사용하여 많은 응용 프로그램을 구축하기 시작했습니다. 두 가지 프레임 워크에 대해 말씀 드리겠습니다.


1
"System.Addin에 대한 비디오를 보면"어떤 비디오? 링크를 제공해 주시겠습니까? 감사합니다
jimjim

1
@Arjang-채널 9에 커플이 있습니다. channel9.msdn.com/Blogs/DanielMoth/Managed-AddIn-Framework
Chris Spicer

60

MAF 응용 프로그램을 개발하고 제공했습니다. MAF에 대한 나의 견해는 다소 황홀합니다.

MAF는 최악의 경우 "결합 해제 된"시스템 또는 "느슨하게 결합 된"시스템입니다. MEF는 "연결된"시스템 또는 "느슨하게 결합 된"시스템입니다.

MAF를 사용하여 실현 한 MAF 이점은 다음과 같습니다.

  1. 응용 프로그램이 실행되는 동안 새 구성 요소를 설치하거나 기존 구성 요소를 업데이트합니다. 응용 프로그램이 실행되는 동안 AddIn을 업데이트하고 업데이트가 사용자에게 완벽하게 나타납니다. 이를 위해 AppDomain이 있어야합니다.

  2. 구매 한 구성 요소를 기반으로하는 라이센스. 우리는 사용자의 역할과 권한에 의해로드 된 AddIn과 AddIn의 사용 허가 여부를 제어 할 수있었습니다.

  3. 빠른 개발 (빠른 시장 출시 시간). AddIn 개발은 Agile 방법론에 완벽하게 부합하며, 개발 팀은 나머지 애플리케이션과 통합을 개발할 필요없이 한 번에 하나의 AddIn을 개발했습니다.

  4. 개선 된 QA (한 번에 하나의 구성 요소 만 품질 보증). 그러면 QA는 단일 기능 비트에 대한 결함을 테스트하고 발행 할 수 있습니다. 테스트 케이스는 개발 및 구현이 더 쉬웠다.

  5. 배포 (구성 요소가 개발 및 릴리스되고 "작동"할 때 추가) 배포는 AddIn을 만들고 파일을 설치하기 만하면됩니다. 다른 고려 사항은 필요하지 않았습니다!

  6. 새로운 구성 요소는 이전 구성 요소와 함께 작동했습니다. 초기에 개발 된 AddIn은 계속 작동했습니다. 새로운 AddIn은 응용 프로그램에 완벽하게 맞습니다


3
.NET 4에서 MEF로 위의 모든 작업을 수행했으며 MAF가 더 간단하다고 생각합니다.
Tim

21
@Jim : 실행하는 동안 기존 MEF 애드 인을 제거 할 수 있습니까? 내가 아는 한 추가 기능 어셈블리는 동일한 AppDomain에 있기 때문에 한 번로드되면 언로드 할 수 없습니다.
Scott Whitlock

6
@Scott-+1 (하나 이상을 제공 할 수 있습니까?) 여기에 나열되지 않은 또 다른 이점 : MAF를 사용하여 addin의 보안 권한을 샌드 박스 할 수 있지만 MEF의 구성 요소가 사용하는 보안 권한은 실행 중과 동일한 권한을 공유합니다 신청.
Doug

2
@ScottWhitlock : 사실이 아닌 여러 AppDomain에서 MEF를 사용할 수 없음을 나타냅니다.
M.Stramm

25

제 생각에 두 기술은 실제로 매우 다른 사용 사례를 대상으로합니다.

MEF는 일반적으로 최종 통합 솔루션을 제공하는 개인 또는 그룹이 모든 것을 조립하고 전체 무결성을 보장하지만 핵심 기능을 다르게 구현해야하는 순수 의존성 주입 시나리오에서 가장 좋습니다.

MAF는 누군가 / 그룹이 플랫폼 또는 호스트를 개발하고 있고 다른 그룹이 사실 후에 호스트 그룹의 통제를받지 않는 방식으로 기능을 추가하는 시나리오를위한 것입니다. 이 시나리오에서는 호스트를 불량 추가 기능으로부터 "보호"하거나 추가 기능을 서로 보호하기위한보다 정교한 메커니즘이 필요합니다.

세 번째 유사한 패턴 기술은 전체 ProviderBase 체계입니다. 이를 통해 기능을 교체 할 수도 있지만 목표는 실제로 호스트 / 앱에 기능이 절대적으로 필요한 시나리오이며 실제로 구성을 통해 다른 구현을 지정해야합니다.


18

MAF와 MEF를 모두 다루는이 긴 기사를 방금 발견했습니다. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

MEF와 MAF의 주요 차이점 중 하나는 Managed Extensibility Framework가 하나의 구성 가능한 부분이 다른 부분에 의존 할 수 있다는 것입니다. 예를 들어, 플러그인이 다른 플러그인에 종속되도록 할 수 있습니다.

또한 Managed Extensibility Framework는 System.AddIn과 마찬가지로 호스트와 추가 기능을 구분하지 않습니다. MEF에 관한 한, 이들은 모두 컴포저 블 부품입니다.


9

내 의견으로는, 차이점을 발견하는 가장 좋은 방법은 실제 코드입니다. 계산기 예제와 함께 두 가지 MSDN 연습을 통해 구현을 쉽게 비교할 수 있습니다.

MEF : 간단한 계산기 예를 사용하여 MEF 부품
( M은 anaged E xtensibility F ramework)

  • MEF 기술을 사용하여 간단한 계산기를 작성하는 방법을 보여줍니다. 외부 dll을로드하는 방법을 보여주지 않습니다. (단, 사용하는 catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); 대신 사용하여 예제를 간단하게 수정할 수 있습니다. catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); 계산기 코드 하고 추출하는 DLL 프로젝트를 분리 할 수 ​​있습니다.
  • MEF 특정 디렉토리 구조를 가질 필요 가 없으며 소규모 프로젝트에서도 간단하고 사용하기 쉽습니다. 그것은 , 속성 작동 읽고 쉽게 이해할 수있는 내보낼 것을 선언. 예: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

  • MEF는 버전 관리를 자동으로 처리하지 않습니다

MAF : V1 및 V2 버전 MAF 플러그인이 포함 된 간단한 계산기
( M anaged A ddin F ramework )

  • V1 플러그인을 사용하여 계산기를 빌드 한 다음 이전 버전과의 호환성을 유지하면서 V2 플러그인으로 이동하는 방법을 보여줍니다 ( 참고 : 여기서 플러그인의 V2 버전을 찾을 수 있음) 에서
  • MAF 특정 디렉토리 구조를 시행 하며 이를 작동시키기 위해서는 많은 상용구 코드가 필요하므로 소규모 프로젝트에는 권장하지 않습니다. 예:
    Pipeline
      AddIns
        CalcV1
        CalcV2
      AddInSideAdapters
      AddInViews
      Contracts
      HostSideAdapters

MEF와 MAF는 모두 .NET Framework 4.x에 포함되어 있습니다. 두 예제를 비교하면 MAF 플러그인이 MEF 프레임 워크에 비해 훨씬 더 복잡하다는 것을 알 수 있습니다. 따라서 어떤 프레임 워크를 사용할지 신중하게 고려해야합니다.


3

MAF와 MEF는 모두 AppDomain을 사용할 수 있으며 런타임시 dll을로드 / 언로드 할 수 있습니다. 그러나 내가 찾은 차이점은 다음과 같습니다. MAF AddIn이 분리되고 MEF 구성 요소가 느슨하게 연결되어 있습니다. MEF는 기본적으로 인스턴스를 만드는 반면 MAF는 "활성화"(새 인스턴스)합니다.

MEF를 사용하면 Generics를 사용하여 모든 계약에 대해 GenericHost를 만들 수 있습니다. 이는 MEF로드 / 언로드 및 구성 요소 관리가 공통 라이브러리에 있으며 일반적으로 사용될 수 있음을 의미합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.