Il nostro team ha recentemente avuto una grande difficoltà nel decidere se sia una buona pratica o meno per le librerie di classi .NET Core registrare le proprie implementazioni con il fatto di fornire un metodo di estensione IServiceCollection come AddMyServices ().
Il mio punto era che è bello farlo perché:
- L'applicazione di primo livello non ha bisogno di conoscere tutti i dettagli del libreria sottostante che verrà utilizzata,
- L'applicazione di livello superiore (in genere la classe di avvio) non è inquinata con riferimenti a tutti gli spazi dei nomi necessari per registrare la sua implementazione.
- Se applicazione di livello superiore vuole fornire la propria implementazione personalizzata di alcune interfacce definito nella libreria di riferimento, può ancora farlo. .NET Core l'iniezione di dipendenza consente registrazioni multiple.
- Se ci sono più applicazioni che fanno riferimento a questa libreria di classi, non è necessario copiare incollare un blocco di ad es. Aggiungi linee di transito a ciascuna applicazione.
I contrasti erano i seguenti:
- Alcune applicazioni di esempio usano l'approccio di registrare tutto il implementazioni nel metodo di avvio di primo livello.
- L'approccio sopra riportato viene utilizzato solo per le funzionalità (ma crea dubbi semantici su ciò che può essere definito una funzione e cosa no). Ancora una biblioteca di classe può nominare funzionalità implementa e fornisce metodi AddFeatureXYZ () distinti nella classe di estensione IServiceCollection.
- L'utilizzo del metodo di estensione AddService () che registra tutte le implementazioni che può fornire può avere un impatto sulle prestazioni del contenitore DI, il che rende senso nel caso in cui alcune librerie di classi forniscono molte impementazioni ma solo pochi sono usati. Ma uno sviluppatore ha ancora una libertà di chiamando AddServices () o no.
Volevo chiedere agli sviluppatori .NET Core più esperti i loro approcci con tutti i professionisti, che forse mi mancano. Se ci sono argomenti validi per utilizzare il secondo approccio che non ho elencato qui, mi piacerebbe davvero conoscerlo.
PS. Questa domanda è stata spostata da StackOverflow in quanto è stata contrassegnata come più basata sull'opinione pubblica. Secondo me sta toccando i principi fondamentali della programmazione orientata agli oggetti, e la questione non è scoprire quale sia la maggioranza degli sviluppatori che sceglie, ma perché qualcuno preferisce un approccio all'altro.
Grazie, Radek