2011-02-10 10 views
8

Corrígeme si me equivoco, pero MEF solo es bueno para administrar un conjunto de cosas desconocidas (complementos) que pueden detectarse automáticamente y conectarse automáticamente. Para un proyecto futuro necesitaremos un contenedor de IoC verdadero para configurar explícitamente las partes conocidas de la aplicación (que MEF no es bueno) pero también necesitamos admitir complementos autodetectados (preferiblemente POCO sin atributos, si eso es posible). ¿Puede un contenedor IoC admitir esto fácilmente/por defecto? Si es así, ¿puede dar una sugerencia rápida de sobre cómo se hace esto en Unity y StructureMap? Esos son los dos que actualmente preferimos. Realmente nos gustaría evitar una dependencia en un contenedor IoC y MEF.Usar el contenedor IoC para la arquitectura de complementos

+0

¿Qué pasa con el uso de MEF para los complementos? Está diseñado exactamente para ese caso de uso, y es parte del framework .Net. – jeroenh

+0

Eche un vistazo a Spring.Net. –

+1

Dijiste que quieres evitar tener un contenedor IoC y MEF, por lo que no lo publicaré como respuesta. Pero [Autofac] (http://nblumhardt.com/2010/04/introducing-autofac-2-1-rtw/) se integra bastante bien con MEF. –

Respuesta

8

Creo que es importante tener en cuenta que, si bien MEF no es un contenedor IoC en un sentido convencional, está realizando una inversión de control. De hecho, estoy en desacuerdo con eso y digo que MEF es un contenedor IoC muy parecido a cualquier otro. La diferencia real entre say Unity y MEF es que MEF admite de forma predeterminada la composición por encima de la resolución de tipo explícito y escribe el descubrimiento sobre la configuración. Pero, como hemos visto con el proyecto MEFContrib, es muy posible que MEF se comporte más como un contenedor IoC tradicional. MEF le proporciona una excelente base para el comportamiento de componentes modulares, eliminando gran parte del injerto duro y la forma en que está diseñado, le permite agregar más funcionalidad. Digamos, por ejemplo, que tiene su base de código existente construida alrededor de otro contenedor IoC o localizador de servicios, puede conectar un ExportProvider para hacerlo, así que puede conectar un proveedor a un localizador de servicios como el proyecto Common Service Locator y luego conectar un compatible Implementación de CSL y tiene componentes de componentes de MEF que usan tipos derivados de su otro contenedor de IoC. MEF también realiza la inyección de dependencia para usted.

Si desea evitar tener una dependencia en un contenedor de IoC específico o MEF, siempre puede usar algo como el Localizador de servicios comunes, que es una abstracción de las operaciones comunes de contenedor. De esa manera, si necesita/desea cambiar la forma en que todo se conecta, es relativamente sencillo. Hay implementaciones de CSL compatibles para la mayoría de los contenedores de IoC y MEF.

Espero que ayude.

+0

¿MEF Contrib permitiría que las piezas sean POCO sin atributos? – bitbonk

+2

El modelo atribuido es solo el modelo de programación predeterminado para MEF. MEFContrib tiene un 'ConventionCatalog', que combinado con' PartRegistry' le permite registrar tipos más parecidos a contenedores como Unity/Autofac/Windsor, etc. –

Cuestiones relacionadas