약 2 주 동안 MEF와 협력 해 왔습니다. MEF가 무엇인지에 대해 생각하고 MEF 사용 방법을 연구하고 3 개의 모듈로 호스트를 구현하기 시작했습니다. 계약은 이해하기 쉬우 며 모듈은 쉽게 관리됩니다.
MEF는 매우 실용적이지만 어느 정도 궁금합니다. 내 말은, 모든 사람이 확장 성을 위해 기존 응용 프로그램을 다시 작성하게 될까요?
그렇습니다. 소리가 나고 비현실적입니다. 수사적으로 말하기 :
MEF는 프로그래밍의 현재 트렌드에 어떤 영향을 미칩니 까?
MEF를 사용할 기회를 찾기 시작 했습니까?
확장성에 도움이 될 수있는 기존 앱의 주요 재 작성을 계획하기 시작 했습니까?
즉, 내 질문은 다음과 같습니다.
확장 성을 갖춘 새 프로젝트를 언제 계획해야하는지 어떻게 알 수 있습니까?
확장 성을 위해 기존 프로젝트를 다시 작성해야하는지 어떻게 알 수 있습니까?
MEF를 사용하는 사람이 있습니까?
답변:
MEF를 사용하는 사람이 있습니까?
MVVM 패턴을 사용하여 Silverlight 프로젝트를 진행하고 있습니다. 인터페이스와 수동 종속성 주입 (필요에 따라 생성자 또는 속성 주입)을 통해 필요에 따라 모든 VM을 함께 연결하는 것으로 시작했습니다. 이제는 고통스러워지기 시작했고 MEF를 기본적으로 의존성 주입 프레임 워크로 사용하여 뷰 모델에서 사용되는 특정 서비스를 내보내고 필요한 뷰 모델로 가져 왔습니다. 아주 작은 코드로 완벽하게 작동합니다.
그렇습니다. MEF가 의존성 주입을위한 것이 아니며 실제 의존성 주입 프레임 워크가 훨씬 더 효과적 이라고 말하는 일부 순수 론자가 있습니다 . 그러나 MEF는 큰 장점 인 .NET으로 바로 구워졌으며 우리의 요구를 충족시키기에 충분했습니다.
확장 성을 갖춘 새 프로젝트를 언제 계획해야하는지 어떻게 알 수 있습니까? 확장 성을 위해 기존 프로젝트를 다시 작성해야하는지 어떻게 알 수 있습니까?
IMO는 항상 우려 사항을 적절히 분리하고 인터페이스를 사용하여 서로 다른 모듈이 독립적으로 변경되도록해야합니다. 이 작업을 올바르게 수행하면 확장 성 이 필요한 경우 MEF를 쉽게 추가 할 수 있습니다. 그러나 확장 성 요구 사항이없는 프로젝트를 시작하지 않고 경우에 따라 MEF를 넣을 수 없습니다. 필요가있을 때까지 기다릴 것입니다. 기존 프로젝트의 경우 필요가 발생하면 MEF 대 대안 솔루션을 사용하는 것보다 다른 솔루션을 사용하지 않고 프로젝트를 재배치하는 노력을 평가하고 어떤 결과를 얻었는지 확인합니다.
사람들이 저지르는 실수 는 MEF가 확장성에 만 실용적이라고 가정 하는 명명 (Managed Extensibility Framework) 때문이라고 생각합니다 . MEF는 실제로 확장 성, 검색 및 메타 데이터의 세 가지 주요 사항을 해결합니다. 마지막 두 개는 단일 플러그인이나 확장을 보지 않는 응용 프로그램에서도 매우 강력합니다.
이 기사는 IOC 컨테이너로 발견 할 수있는 힘에 대해 쓴 기사입니다. http://www.informit.com/articles/article.aspx?p=1635818
대부분의 엔터프라이즈 비즈니스 응용 프로그램에서 MEF를 사용하므로 Silverlight에서 모듈 식 응용 프로그램을보다 빠르고 쉽게 구축하고 유지 관리 할 수 있습니다.