.NET용 Managed Extensibility Framework는 어디에 있습니까?

StackOverflow https://stackoverflow.com/questions/42251

  •  09-06-2019
  •  | 
  •  

문제

Microsoft의 MEF(Managed Extensibility Framework)를 사용해 많은 작업을 해본 사람이 있습니까?모든 사람에게 모든 것을 제공하려는 것처럼 들립니다. 추가 기능 관리자입니다!오리 타이핑입니다!긍정적이든 부정적이든 경험해 본 사람이 있는지 궁금합니다.

우리는 현재 다음 대규모 프로젝트에 MvcContrib라는 일반 IoC 구현을 사용할 계획입니다.MEF를 혼합해야 할까요?

도움이 되었습니까?

해결책

우리는 MEF가 다목적 IoC가 되는 것을 목표로 하지 않습니다.MEF의 IoC 측면을 고려하는 가장 좋은 방법은 구현 세부 사항입니다.우리는 IoC가 우리가 해결하려는 문제를 해결하는 좋은 방법이기 때문에 패턴으로 사용합니다.

MEF는 확장성에 중점을 둡니다.MEF를 생각할 때 이를 플랫폼을 발전시키기 위한 투자로 생각하십시오.향후 제품과 플랫폼에서는 MEF를 확장성을 추가하기 위한 표준 메커니즘으로 활용할 것입니다.타사 제품 및 프레임워크에서도 이와 동일한 메커니즘을 활용할 수 있습니다.MEF의 평균 "사용자"는 MEF가 사용할 구성 요소를 작성하며 애플리케이션 내에서 MEF를 직접 사용하지 않습니다.

나중에 우리 플랫폼을 확장하고 싶을 때 bin 폴더에 dll을 넣으면 작업이 완료된다고 상상해 보세요.MEF 지원 앱이 새 확장으로 표시됩니다.이것이 MEF의 비전입니다.

다른 팁

이 게시물은 Managed Extensibility Framework Preview 2를 참조합니다.

그래서 저는 MEF를 실행하고 아래에 제시된 간단한 "Hello World"를 작성했습니다.나는 그것에 뛰어 들고 이해하기가 완전히 쉽다고 말하고 싶습니다.카탈로그 시스템은 훌륭하며 MEF 자체를 매우 간단하게 확장할 수 있습니다.추가 기능 어셈블리 디렉터리를 가리키고 나머지를 처리하도록 하는 것은 간단합니다.MEF의 전통인 ala Prism은 확실히 드러나지만 두 프레임워크 모두 구성에 관한 것이므로 그렇지 않다면 이상할 것이라고 생각합니다.

내 생각에 가장 마음에 남는 것은 _container.Compose()의 "마법"이라고 생각합니다.HelloMEF 클래스를 살펴보면 인사말 필드가 코드에 의해 결코 초기화되지 않는다는 것을 알 수 있습니다. 이는 단지 웃기게 느껴질 뿐입니다.나는 IoC 컨테이너가 작동하는 방식을 선호한다고 생각합니다. 즉, 컨테이너에 개체를 빌드하도록 명시적으로 요청하는 방식입니다.일종의 "아무것도" 또는 "빈" 일반 초기화 프로그램이 올바른지 궁금합니다.즉.

private IGreetings greetings = CompositionServices.Empty<IGreetings>();

이는 적어도 컨테이너 구성 코드가 실행되어 실제 "무언가"로 개체를 채울 때까지 개체를 "무언가"로 채웁니다.잘 모르겠습니다. 제가 항상 싫어했던 Visual Basic의 비어 있거나 없음 키워드와 약간 비슷합니다.다른 사람이 이에 대해 생각이 있다면 듣고 싶습니다.어쩌면 그것은 내가 극복해야 할 것일 수도 있습니다.큼직한 [가져오기] 속성이 표시되어 있어서 완전한 미스터리라거나 그런 것은 아닙니다.

개체 수명 제어는 명확하지 않지만 내보낸 클래스에 [CompositionOptions] 특성을 추가하지 않는 한 기본적으로 모든 것이 싱글톤입니다.그러면 Factory 또는 Singleton을 지정할 수 있습니다.언젠가 이 목록에 Pooled가 추가되면 좋을 것 같습니다.

덕 타이핑 기능이 어떻게 작동하는지 잘 모르겠습니다.덕 타이핑보다는 객체 생성 시 메타데이터 주입에 더 가깝습니다.그리고 오리 한 마리만 추가할 수 있는 것 같습니다.하지만 앞서 말했듯이 이러한 기능이 어떻게 작동하는지 아직은 확실하지 않습니다.나중에 다시 돌아와서 이 내용을 작성할 수 있기를 바랍니다.

DirectoryPartCatalog에 의해 로드된 DLL을 섀도우 복사하는 것이 좋은 생각이라고 생각합니다.현재 MEF가 DLL을 확보하면 DLL이 잠깁니다.이를 통해 디렉토리 감시자를 추가하고 업데이트된 추가 기능을 포착할 수도 있습니다.그거 꽤 달콤할텐데...

마지막으로, 추가 기능 DLL이 얼마나 신뢰할 수 있는지, 그리고 MEF가 부분 신뢰 환경에서 어떻게 작동할지 또는 작동할지 여부가 걱정됩니다.MEF를 사용하는 애플리케이션에는 완전 신뢰가 필요할 것으로 생각됩니다.자체 AppDomain에 추가 기능을 로드하는 것이 현명할 수도 있습니다.나는 이것이 System.AddIn과 약간 비슷하다는 것을 알고 있지만 사용자 추가 기능과 시스템 추가 기능을 매우 명확하게 구분할 수 있습니다.

알았어 - 수군거리는 건 그만둬.다음은 MEF 및 C#의 Hello World입니다.즐기다!

using System;
using System.ComponentModel.Composition;
using System.Reflection;

namespace HelloMEF
{
    public interface IGreetings
    {
        void Hello();
    }

    [Export(typeof(IGreetings))]
    public class Greetings : IGreetings
    {
        public void Hello()
        {
            Console.WriteLine("Hello world!");
        }
    }

    class HelloMEF : IDisposable
    {
        private readonly CompositionContainer _container;

        [Import(typeof(IGreetings))]
        private IGreetings greetings = null;

        public HelloMEF()
        {
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
            _container = new CompositionContainer(catalog);
            var batch = new CompositionBatch();
            batch.AddPart(this);
            container.Compose(batch);

        }

        public void Run()
        {
            greetings.Hello();
        }

        public void Dispose()
        {
            _container.Dispose();
        }

        static void Main()
        {
            using (var helloMef = new HelloMEF())
                helloMef.Run();
        }
    }
}

MEF가 로드하는 확장에 대한 보안에 대한 Andy의 질문(죄송하지만 아직 포인트가 충분하지 않습니다 :))에 대해 이 문제를 해결할 수 있는 곳은 카탈로그입니다.MEF 카탈로그는 완전히 연결 가능하므로 로드하기 전에 어셈블리 키 등의 유효성을 검사하는 사용자 지정 카탈로그를 작성할 수 있습니다.원한다면 CAS를 사용할 수도 있습니다.우리는 카탈로그를 작성하지 않고도 이 작업을 수행할 수 있도록 후크를 제공할 수 있는 방법을 모색하고 있습니다.그러나 현재 카탈로그의 소스는 무료로 사용할 수 있습니다.나는 최소한의 것은 누군가(아마도 우리 팀)가 하나를 구현하고 CodePlex의 확장/기여 프로젝트에 던질 것이라고 생각합니다.

덕 타이핑은 현재 드롭에 있지만 V1에는 제공되지 않습니다.향후 출시에서는 덕 타이핑 메커니즘에 연결할 수 있는 플러그형 어댑터 메커니즘으로 교체할 예정입니다.덕 타이핑을 살펴본 이유는 버전 관리 시나리오를 해결하기 위한 것입니다.Duck Typing을 사용하면 수출업자와 수입업자 사이의 공유 참조를 제거할 수 있으므로 여러 버전의 계약이 나란히 존재할 수 있습니다.

Andy, 저는 Glenn Block이 MSDN MEF 포럼의 이 스레드에서 다음과 같은 많은 사람들의 (자연스러운) 질문에 대답한다고 믿습니다.

CompositionContainer와 기존 IoC 컨테이너 비교 .

어느 정도 위의 Artem의 대답은 구성이 아닌 확장성인 MEF의 기본 의도와 관련하여 정확합니다.주로 구성에 관심이 있다면 다른 일반적인 IoC 용의자 중 하나를 사용하십시오.반면에 주로 확장성에 관심이 있다면 카탈로그, 부품, 메타데이터 태그 지정, 덕 타이핑 및 지연된 로드의 도입이 모두 몇 가지 흥미로운 가능성을 만들어줍니다.또한 Krzysztof Cwalina가 슛을 날립니다. 여기 MEF와 System.Addins가 서로 어떻게 관련되어 있는지 설명합니다.

컨트롤 용기를 주입하는 것이 아닙니다.플러그인 지원 프레임워크입니다.

.NET 4.0 Framework의 'System' 네임스페이스에서 벗어나게 되므로 크게 잘못될 수는 없을 것입니다.MEF가 어떻게 진화하는지, Hamilton Verissimo(Castle)가 MEF의 방향에 어떤 영향을 미치는지 지켜보는 것도 흥미로울 것입니다.

오리처럼 꽥꽥거린다면 현재 IoC 컨테이너 무리의 일부일 수도 있습니다.

이 게시물과 댓글에서 이에 대한 자세한 논의가 이루어졌습니다.

http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top