• RSS
  • Facebook
  • Twitter
  • Linkedin
  • Google +
  • Youtube

Vamos a explicar una forma más cómoda que la tradicional en cómo definimos la colaboraciones entre objetos al inyectar las dependencias con Spring.NET (IoC).

Para ello, vamos a exponer la forma básica con la que definimos la colaboración entre objetos:

<?xml version="1.0" encoding="utf-8" ?>
<objects xmlns="http://www.springframework.net">
  <object id="objetoA" type="Proyecto.Core.ClaseA, Proyecto.Core" singleton="false">
  </object>
  <object id="objetoB" type="Proyecto.Core.ClaseB, Proyecto.Core" singleton="false">
  </object>
  <object id="objetoC" type="Proyecto.Core.ClaseC, Proyecto.Core" singleton="false">
  </object>
  <object id="objetoD" type="Proyecto.Core.ClaseD, Proyecto.Core" singleton="false">
  </object>

  <object id="objetoE" type="Proyecto.Core.ClaseE, Proyecto.Core" singleton="false">
      <property name="ObjetoA" ref="objetoA"/>
      <property name="ObjetoB" ref="objetoB"/>
      <property name="ObjetoC" ref="objetoC"/>
      <property name="ObjetoD" ref="objetoD"/>
  </object>

</objects>

Esta es la forma tradicional de definición para inyectar al objetoE todas sus propiedades que necesita para poder funcionar. Como podéis ver es una forma muy tediosa y muy dada al error, ya que al ser un XML podemos equivocarnos al escribir una propiedad y sólo nos daremos cuenta que está mal al tener la aplicación en marcha.. con todos los problemas que conlleva.

Para resolver esta circunstancia, Spring implementó en su momento una forma de definición “autowiring” que quiere decir más o menos “auto conexión”. Esta forma de definición delega en Spring el proceso de asignar a cada objeto sus colaboradores. Y muchos os preguntaréis, ¿cómo sabes Spring qué tipo de colaboradores debe asignar a un objeto?

Spring no hace magia 😉 para ello usa varias técnicas de “rastreo” que podemos definir para que “intente” asignar los colaboradores a los objetos que crea en su contenedor.

Tipos de autowiring:

  • No: es el valor por defecto, define que el programador es el encargado de relacionar colaboradores con un objeto.
  • ByName: esta opción inspecciona el contenedor y busca entre sus objetos alguno que tenga el mismo nombre de instancia.
  • ByType: tiene la habilidad de resolver la colaboración por el nombre del tipo de instancia.
  • Constructor: funciona igual que la de “ByType”, lo que hace es buscar el constructor que encaje con los argumentos definidos en la clase.
  • Autodetect: esta es la consecución de otras, es decir, primero hace un rastreo buscando un constructor adecuado y si no encuentra, lanza el autowiring de “ByType”.

Aplicando el autowiring al ejemplo anterior nos quedaría así:


<?xml version="1.0" encoding="utf-8" ?>
<objects xmlns="http://www.springframework.net">
  <object id="objetoA" type="Proyecto.Core.ClaseA, Proyecto.Core" singleton="false">
  </object>
  <object id="objetoB" type="Proyecto.Core.ClaseB, Proyecto.Core" singleton="false">
  </object>
  <object id="objetoC" type="Proyecto.Core.ClaseC, Proyecto.Core" singleton="false">
  </object>
  <object id="objetoD" type="Proyecto.Core.ClaseD, Proyecto.Core" singleton="false">
  </object>

  <object id="objetoE" type="Proyecto.Core.ClaseE, Proyecto.Core" singleton="false" autowire="byType">
  </object>

</objects>

Simplemente añadiendo en la definición del objetoE el autowiring, nos evita tener que asociarle sus colaboradores manualmente, Spring se encargará automáticamente de buscar los colaboradores que necesita el objetoE.

Realmente es una técnica que nos facilita mucho la vida y nos ahorra trabajo de escritura, pero también hay que ser muy consciente de lo que ello implica y las consecuencias que nos puede llevar.

The following two tabs change content below.
Empresa de Hosting & IT Consulting

Latest posts by Domitienda (see all)

Categorías: .NET

Deja un comentario