Inyectar dependencia como parámetro de método en lugar de parámetro de constructor

7

Estoy usando un ORM que no me permite inyectar dependencias en el constructor. Digamos que estoy usando DDD para la lógica de negocios y el patrón MVC para la interfaz de usuario.

Ahora uno de mis objetos de dominio necesita acceder a un servicio externo. Soy muy contrario al anti-patrón del localizador de servicios (no lo tocaría con un palo de diez pies), pero como lo veo, eso me deja con lo siguiente:

class Controller
{
    private readonly IExternalService _externalService;

    public Controller(IExternalService externalService)
    {
        _externalService = externalService;
    }

    public ViewResult Action(Guid Id)
    {
        // Omitted repository access for brevity.
        domainObject.DoSomethingWichNeedsAnExternalService(_externalService);
    }
}

De alguna manera, tengo la sensación de que esto no está muy limpio, ¿qué sucede si el "domainObject" está enterrado profundamente en el modelo / gráfico, si el "_externalService" se pasa por completo?

¿Existen alternativas de mejores prácticas?

    
pregunta dvdvorle 02.09.2011 - 23:43

3 respuestas

2

Parece que se irá de las manos. Por ejemplo, tuve que usar un IRealTimeClockService para inyectar en mis unidades bajo prueba para poder tener resultados de prueba repetibles para cosas que dependen de la hora del sistema. Eso parece mucho peso para un servicio que solo llama a DateTime.Now . Pero debo admitir que realmente no ha hecho que el código sea menos legible, a pesar de que también tiene que pasarlo a los constructores de la clase base.

De alguna manera es mejor porque es obvio cuáles son tus dependencias.

Si tienes muchas dependencias inyectadas en un objeto, eso podría significar que estás violando el principio de responsabilidad única, y esa clase podría dividirse en algo que hace dos cosas no relacionadas.

Por otro lado, si tiene un sistema complejo, tendrá objetos complejos con muchas dependencias. Creo que es mejor ser explícito al respecto.

Algo a considerar: si su clase A toma 5 dependencias y pasa 4 de ellas a un objeto auxiliar sin tocarlas, tal vez debería reemplazar esos 4 con una dependencia del objeto auxiliar (o una interfaz, obviamente ).

    
respondido por el Scott Whitlock 03.09.2011 - 01:16
1

Lo que he hecho es crear una clase de fábrica que crea todas las demás instancias y las une. Entonces, no tiene que pasar objetos dependientes a través de constructores: proporcione a la fábrica las instancias de reemplazo y haga que compile todo lo demás.

    
respondido por el Jeff Grigg 03.09.2011 - 02:15
1

¿No estaría envolviendo la opción API de ORM, para que pueda pasar lo que quiera al constructor de su envoltorio?

En general, cuando se trata de apis externos, puede que no sea una mala idea hacerlo. Además, está menos vinculado al ORM, lo que puede ser bueno en el futuro.

    
respondido por el devoured elysium 03.09.2011 - 02:23

Lea otras preguntas en las etiquetas