configuration - site - tag manager acceso
¿Se debe configurar Unity en código o archivo de configuración? (3)
El marco de inyección de dependencia de Unity de Microsoft se puede configurar a través del código o del archivo de configuración de aplicaciones (app.config).
Ejemplo de código:
IUnityContainer container = new UnityContainer()
.RegisterType<IInterface, ConcreteImplementation>();
Ejemplo de configuración:
<unity>
<containers>
<container>
<types>
<type type="IInterface, MyAssembly"
mapTo="ConcreteImplementation, MyAssembly" />
¿Cuáles son las ventajas / desventajas de cada enfoque? Puedo pensar en la ventaja obvia "Los usuarios pueden configurar fácilmente su aplicación", y la desventaja obvia "Los usuarios pueden romper su aplicación fácilmente", pero ¿hay algo menos obvio?
La configuración XML es realmente solo beneficiosa para una sola cosa: el enlace tardío . Con la configuración XML puede cambiar la composición de su aplicación sin volver a compilar la aplicación completa. Esto es particularmente relevante para las aplicaciones de ISV que admiten cierto grado de configuración del usuario . Los ISV pueden enviar una aplicación compilada con un comportamiento predeterminado, pero permiten a los clientes / usuarios cambiar partes del comportamiento cambiando la configuración.
Sin embargo, la configuración XML es frágil y detallada . Desde el punto de vista de un desarrollador, es un dolor trabajar con él.
- La configuración tiende a romperse cuando cambia el nombre de tipos o conjuntos.
- Debe copiar manualmente los .dlls apropiados en el directorio de salida (o hacer que un script de compilación lo haga).
- La verbosidad general hace que sea difícil trabajar con él.
- El soporte de la herramienta es más débil que para el código fuertemente tipado.
Como regla general, prefiera el código como configuración . Sin embargo, puede hacer coincidir el Código con la Configuración con la configuración XML, por lo que si tiene algunas dependencias que deberían estar vinculadas con retraso, puede usar la configuración XML para ellas.
La pregunta ya está respondida pero quiero resumir mi experiencia:
Usa ambos. Estoy ocultando la configuración de código en la extensión, cuando tengo varias configuraciones estándar (normalmente, porque uso IoC) tengo varias extensiones que comparten la configuración principal.
Estoy usando la configuración XML para tareas no estándar como el ajuste de rendimiento (en el entorno donde la recompilación lleva mucho tiempo).
Una desventaja importante de la configuración a través del código es que el código requiere una referencia a los ensamblajes. Esto significa que tengo que agregar referencias de proyecto o DLL en el proyecto para que el código se compile.
La inyección de dependencia se supone que elimina las dependencias entre los componentes. La inicialización a través del código reintroduce la dependencia al requerir referencias a proyectos o DLL. El archivo de configuración XML puede hacer referencia a cualquier conjunto.
Si creo una nueva implementación basada en una interfaz, puedo integrar la nueva implementación en una aplicación existente agregando la DLL compilada y actualizando el archivo de configuración XML. Si hago la configuración a través del código, tengo que volver a compilar la aplicación para reemplazar una implementación.