Es hora de hablar sobre “Inversion of Control”:
El Problema
Qué observamos en el código anterior:
- La clase SmtpClient está directamente referenciada por la clase HomeController y está última controla su creación, lo que tiene como consecuencia un fuerte acoplamiento entre estas dos clases.
- La clase HomeController es consciente de la clase SmtClient y su funcionamiento, por lo tanto si alguna vez tenemos que realizar algún cambio sobre el envió de correo: como enviarlo por una cola de mensajes o incluso cambiar por una nueva librería, la clase HomeController se verá afectada.
- Se dificulta la realización de pruebas sobre la clase HomeController.
La Solución
Si somos capaces de cambiar el control de la creación de la clase SmtpClient a una tercera entidad, podremos ver resuelto nuestro problema. Y esa solución es: Inversion of Control.
Inversion of Control
“Is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to traditional architecture of software”
Wikipedia
Podemos implementar este patrón de 2 maneras distintas:
Dependency Inyeccion
La idea es tener un objeto en el “mundo exterior” que se encargue de proveer o inyectar la implementación adecuada (EmailSender) a la clase listener (HomeController)
Service Locator
La idea es tener una entidad “dentro de la clase” que conozca cómo obtener la implementación adecuada que esta clase podría necesitar.
Ahora veamos cómo estas cosas se utilizan en nuestra aplicación de ejemplo y adicionalmente veremos como podemos configurarla para que levante y ejecute.
No se olviden de ver el resto de la serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.
Saludos
