Inietta dipendenza come parametro metodo anziché parametro costruttore

Question

Inietta dipendenza come parametro metodo anziché parametro costruttore

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

7

Sto usando un ORM che non mi permette di iniettare dipendenze nel costruttore. Diciamo che sto usando DDD per la business logic e il pattern MVC per l'interfaccia utente.

Ora uno dei miei oggetti di dominio deve accedere a un servizio esterno. Sono molto contrario all'anti-pattern del localizzatore di servizi (non lo toccherei con un palo di dieci piedi), ma come vedo, questo mi lascia con il seguente:

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);
    }
}

In qualche modo ho la sensazione che questo non sia molto pulito, e se il "domainObject" è sepolto in profondità nel modello / grafico, se "_externalService" dovesse essere passato completamente giù?

Esistono alternative di best practice?

c# domain-driven-design inversion-of-control service-locator

posta dvdvorle 02.09.2011 - 23:43

fonte

3 risposte

1

Quello che ho fatto è creare una classe factory che crea tutte le altre istanze e le unisce. Quindi non devi passare oggetti dipendenti tramite costruttori: dai alla fabbrica le istanze di sostituzione e costruisci tutto il resto.

risposta data 03.09.2011 - 02:15

fonte

1

Non sarebbe possibile avvolgere l'API di ORM in un'opzione, in modo da poter passare tutto ciò che si desidera al costruttore del wrapper?

In generale, quando si parla di apis esterni, potrebbe non essere una cattiva idea farlo. Inoltre, sei meno legato all'ORM, che potrebbe essere un bel futuro.

risposta data 03.09.2011 - 02:23

fonte

Leggi altre domande sui tag c# domain-driven-design inversion-of-control service-locator

Come si possono distinguere i buoni programmatori da quelli medi? [duplicare] Come sviluppatore C #, quanto Java "avanzato" ho bisogno per lo sviluppo di Android? [chiuso]

score 2 · Accepted Answer

Sembra che ti sfugga di mano. Per esempio, ho dovuto usare un IRealTimeClockService per iniettare nelle mie unità sotto test in modo che potessi avere risultati di test ripetibili per cose che dipendono dall'ora del sistema. Sembra un sacco di peso per un servizio che chiama solo DateTime.Now . Ma devo ammettere che in realtà non ha reso il codice meno leggibile, anche se devi passarlo anche ai costruttori della classe base.

In un certo senso è meglio perché è ovvio quali sono le tue dipendenze.

Se hai un sacco di dipendenze iniettate in un oggetto, questo potrebbe significare che stai violando il principio di responsabilità singola, e quella classe potrebbe essere suddivisa in qualcosa che fa due cose non correlate.

D'altra parte, se si dispone di un sistema complesso, si avranno oggetti complessi con molte dipendenze. Penso che sia meglio essere espliciti al riguardo.

Qualcosa da considerare: se la tua classe A prende 5 dipendenze e ne passa 4 su un oggetto helper senza toccarle, forse dovresti semplicemente sostituire quelle 4 con una dipendenza dall'oggetto helper (o un'interfaccia, ovviamente ).