In questo modo sto scrivendo questo codice è verificabile, ma mi manca qualcosa che non va?

Ho un'interfaccia chiamata IContext. A tal fine, non importa cosa fa, tranne quanto segue:

T GetService<T>();

Quello che fa questo metodo è guardare l'attuale contenitore DI dell'applicazione e tenta di risolvere la dipendenza. Penso che sia abbastanza standard.

Nella mia applicazione ASP.NET MVC, il mio costruttore ha questo aspetto.

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetService<ISomeService>();
    AnotherService = ctx.GetService<IAnotherService>();
}

Quindi, piuttosto che aggiungere più parametri nel costruttore per ogni servizio (perché questo diventerà davvero fastidioso e dispendioso in termini di tempo per gli sviluppatori che estendono l'applicazione) Sto usando questo metodo per ottenere servizi.

Ora, si sente male . Tuttavia, il modo in cui attualmente lo giustifico nella mia testa è questo: posso deriderlo .

Io posso. Non sarebbe difficile prendere in giro IContextper testare il controller. Dovrei comunque:

public class MyMockContext : IContext
{
    public T GetService<T>()
    {
        if (typeof(T) == typeof(ISomeService))
        {
            // return another mock, or concrete etc etc
        }

        // etc etc
    }
}

Ma come ho detto, sembra sbagliato. Eventuali pensieri / abusi sono benvenuti.

Avere uno invece di molti parametri nel costruttore non è la parte problematica di questo progetto . Finché la tua IContextclasse non è altro che una facciata di servizio , in particolare per fornire le dipendenze utilizzate MyControllerBasee non un localizzatore di servizi generale utilizzato in tutto il tuo codice, quella parte del tuo codice è IMHO ok.

Il tuo primo esempio potrebbe essere cambiato in

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetSomeService();
    AnotherService = ctx.GetAnotherService();
}

quello non sarebbe un cambiamento sostanziale di progettazione di MyControllerBase. Se questo disegno è buono o cattivo dipende solo dal fatto se lo desideri

• assicurati TheContext, SomeServicee AnotherServicesono sempre tutti inizializzati con oggetti finti, o tutti con oggetti reali
• oppure, per consentire l'inizializzazione con diverse combinazioni dei 3 oggetti (il che significa che in questo caso è necessario passare i parametri singolarmente)

Pertanto, l'utilizzo di un solo parametro anziché 3 nel costruttore può essere del tutto ragionevole.

La cosa problematica è IContextesporre il GetServicemetodo in pubblico. IMHO dovresti evitarlo, invece mantieni espliciti i "metodi di fabbrica". Quindi sarà ok implementare i metodi GetSomeServicee GetAnotherServicedal mio esempio usando un localizzatore di servizi? IMHO che dipende. Fino a quando la IContextclasse continua a diventare una semplice fabbrica astratta allo scopo specifico di fornire un elenco esplicito di oggetti di servizio, questo è accettabile per IMHO. Le fabbriche astratte sono in genere solo codice "colla", che non deve essere testato da solo. Tuttavia, dovresti chiederti se nel contesto di metodi come GetSomeService, se hai davvero bisogno di un localizzatore di servizi, o se una chiamata esplicita del costruttore non sarebbe più semplice.

Quindi fai attenzione, quando ti attieni a un progetto in cui l' IContextimplementazione è solo un involucro attorno a un GetServicemetodo pubblico e generico , che consente di risolvere eventuali dipendenze arbitrarie da classi arbitrarie, allora tutto applica ciò che @BenjaminHodgson ha scritto nella sua risposta.

Questo design è noto come Service Locator * e non mi piace. Ci sono molti argomenti contrari:

Service Locator ti accoppia al tuo container . Usando l'iniezione regolare di dipendenze (in cui il costruttore spiega esplicitamente le dipendenze) puoi facilmente sostituire il tuo contenitore con uno diverso o tornare a new-espressioni. Con il tuo IContextnon è davvero possibile.

Service Locator nasconde le dipendenze . Come cliente, è molto difficile dire di cosa hai bisogno per costruire un'istanza di una classe. Hai bisogno di una sorta di IContext, ma devi anche impostare il contesto per restituire gli oggetti corretti al fine di far MyControllerBasefunzionare il lavoro. Questo non è affatto ovvio dalla firma del costruttore. Con un normale DI il compilatore ti dice esattamente di cosa hai bisogno. Se la tua classe ha molte dipendenze, dovresti provare quel dolore perché ti stimolerà a fare il refactoring. Service Locator nasconde i problemi con progetti errati.

Service Locator causa errori di runtime . Se chiami GetServicecon un parametro di tipo errato otterrai un'eccezione. In altre parole, la vostra GetServicefunzione non è una funzione totale. (Le funzioni totali sono un'idea del mondo FP, ma fondamentalmente significa che le funzioni dovrebbero sempre restituire un valore.) Meglio lasciare che il compilatore ti aiuti e ti dica quando hai sbagliato le dipendenze.

Service Locator viola il principio di sostituzione di Liskov . Poiché il suo comportamento varia in base all'argomento del tipo, Service Locator può essere visualizzato come se avesse effettivamente un numero infinito di metodi sull'interfaccia! Questo argomento è spiegato in dettaglio qui .

Service Locator è difficile da testare . Hai fornito un esempio di un falso IContextper i test, il che va bene, ma sicuramente è meglio non dover scrivere quel codice in primo luogo. Basta iniettare direttamente le dipendenze false, senza passare dal localizzatore di servizi.

In breve, non farlo . Sembra una soluzione seducente al problema delle classi con molte dipendenze, ma alla lunga renderai la tua vita miserabile.

_{* Sto definendo Service Locator come un oggetto con un Resolve<T>metodo generico che è in grado di risolvere dipendenze arbitrarie e viene utilizzato in tutto il codebase (non solo nel Root di composizione). Questo non è lo stesso di Service Facade (un oggetto che raggruppa un piccolo insieme noto di dipendenze) o Abstract Factory (un oggetto che crea istanze di un singolo tipo: il tipo di una Fabbrica astratta può essere generico ma il metodo non lo è) .}

I migliori argomenti contro l'anti-pattern di Service Locator sono chiaramente indicati da Mark Seemann, quindi non entrerò troppo nel perché questa è una cattiva idea - è un viaggio di apprendimento che devi prendere il tempo di capire da solo (I consiglio anche il libro di Mark ).

OK, quindi per rispondere alla domanda - riaffermiamo il tuo vero problema :

Quindi, piuttosto che aggiungere più parametri nel costruttore per ogni servizio (perché questo diventerà davvero fastidioso e dispendioso in termini di tempo per gli sviluppatori che estendono l'applicazione) Sto usando questo metodo per ottenere servizi.

C'è una domanda che risolve questo problema su StackOverflow . Come menzionato in uno dei commenti lì:

La migliore osservazione: "Uno dei meravigliosi benefici dell'iniezione del costruttore è che rende palesemente evidenti le violazioni del principio della responsabilità singola".

Stai cercando nel posto sbagliato la soluzione al tuo problema. È importante sapere quando una lezione sta facendo troppo. Nel tuo caso sospetto fortemente che non sia necessario un "controller di base". In effetti, in OOP non c'è quasi sempre bisogno di eredità . Le variazioni nel comportamento e la funzionalità condivisa possono essere ottenute interamente attraverso un uso appropriato delle interfacce, che di solito si traduce in un migliore codice fattorizzato e incapsulato - e non è necessario passare dipendenze ai costruttori di superclassi.

In tutti i progetti su cui ho lavorato dove è presente un controller di base, è stato fatto esclusivamente allo scopo di condividere proprietà e metodi convenienti, come IsUserLoggedIn()e GetCurrentUserId(). STOP . Questo è un orribile abuso dell'eredità. Invece, crea un componente che esponga questi metodi e prendi una dipendenza da esso dove ne hai bisogno. In questo modo, i componenti rimarranno testabili e le loro dipendenze saranno evidenti.

A parte qualsiasi altra cosa, quando uso il modello MVC consiglierei sempre i controller skinny . Puoi leggere di più su questo qui, ma l'essenza del modello è semplice, che i controller in MVC dovrebbero fare solo una cosa: gestire gli argomenti passati dal framework MVC, delegando altre preoccupazioni ad altri componenti. Questo è di nuovo il principio della responsabilità singola al lavoro.

Sarebbe davvero utile conoscere il tuo caso d'uso per dare un giudizio più accurato, ma onestamente non riesco a pensare a nessuno scenario in cui una classe base è preferibile a dipendenze ben ponderate.

Sto aggiungendo una risposta a questo sulla base dei contributi di tutti gli altri. Mille grazie a tutti. Prima di tutto ecco la mia risposta: "No, non c'è niente di sbagliato in questo".

La risposta "Service Facade" di Doc Brown Ho accettato questa risposta perché quello che stavo cercando (se la risposta era "no") era qualche esempio o qualche espansione su quello che stavo facendo. Ha fornito questo suggerendo che A) ha un nome e B) ci sono probabilmente modi migliori per farlo.

Risposta di "Service Locator" di Benjamin Hodgson Per quanto apprezzo le conoscenze acquisite qui, quello che ho non è un "Service Locator". È una "facciata di servizio". Tutto in questa risposta è corretto ma non per le mie circostanze.

Risposte dell'USR

Lo affronterò più in dettaglio:

Stai cedendo molte informazioni statiche in questo modo. Stai rinviando le decisioni al runtime come fanno molti linguaggi dinamici. In questo modo perdi la verifica statica (sicurezza), la documentazione e il supporto degli strumenti (completamento automatico, refactoring, ricerca di usi, flusso di dati).

Non perdo alcun attrezzo e non perdo nessuna digitazione "statica". La facciata del servizio restituirà ciò che ho configurato nel mio contenitore DI, oppure default(T). E ciò che restituisce è "digitato". Il riflesso è incapsulato.

Non vedo perché l'aggiunta di servizi aggiuntivi come argomenti del costruttore sia un grosso onere.

Non è certamente "raro". Dato che sto usando un controller di base , ogni volta che devo cambiare il suo costruttore, potrei dover cambiare altri 10, 100, 1000 controller.

Se si utilizza un framework di iniezione delle dipendenze, non sarà nemmeno necessario passare manualmente i valori dei parametri. Quindi perdi alcuni vantaggi statici ma non così tanti.

Sto usando l'iniezione di dipendenza. Questo è il punto.

E infine, il commento di Jules sulla risposta di Benjamin non sto perdendo alcuna flessibilità. È la mia facciata di servizio. Posso aggiungere tutti i parametri a GetService<T>cui voglio distinguere tra diverse implementazioni, proprio come si farebbe quando si configura un contenitore DI. Quindi, ad esempio, potrei cambiare GetService<T>()per GetService<T>(string extraInfo = null)aggirare questo "potenziale problema".

Comunque grazie ancora a tutti. È stato davvero utile. Saluti.