Castle Windsor CollectionResolver: ¿Por qué no funciona en Resolver llamadas?

Question

He agregado el CollectionResolver como un sub-resolver de mi kernel de Windsor, y se inyectará apropiadamente colecciones de dependencias en objetos resueltos. Es decir, si tengo

class X { public X(IComponent[] components) { ... } } 
container.Register(/* lots of IComponents */); 
container.Register(Component.For<X>()); 

el argumento components al constructor se construye correctamente cuando resuelvo que

container.Resolve<X>() 

pero si en cambio sólo me gustaría obtener la lista de componentes en sí,

container.Resolve<IComponent[]>() 

me sale una excepción ComponentNotFound quejándose de que no he registrado ninguna componentes para IComponent[]. Encuentro que esta asimetría es contradictoria ya que no estoy seguro de por qué el kernel debería actuar de manera diferente cuando está resolviendo dependencias que encontró en constructores/propiedades en comparación con cuando está resolviendo dependencias que su usuario desearía resolver.

Answer 1

La división explícita para Resolve/ResolveAll se debe a detalles de implementación internos y poco interesantes en el contenedor. El sistema de resolución de la colección es un dependiente resolver y como tal solo funciona para las dependencias.

Estoy de acuerdo en que no es realmente intuitivo. Siéntase libre de registrar un ticket en el rastreador de problemas de Windsor al respecto.

Answer 2

Supongo que la razón de este comportamiento es que en la propiedad del constructor o de la propiedad, Castle utiliza la notación de colección/matriz como un indicador de que todas las implementaciones deben devolverse en la colección. De lo contrario, necesitarías una interfaz especial o un atributo para decírselo. Y luego tendrías que hacer referencia explícita a las asambleas de Castle en todas partes.

Al resolver directamente desde el contenedor, sin embargo, en realidad está especificando el tipo que necesita resolverse y puede ser mucho más expresivo (usando la API) y puede llamar al ResolveAll explícitamente. Así que supongo que fue un compromiso de diseño: la implementación de contenedores IoC no es tan simple porque a menudo estás obligado por los constructos del lenguaje.