Considerando una soluzione che ha un DI manuale, come la classe sotto, c'è un modo migliore di gestire le implementazioni concrete senza aggiungere un container. Questo è teorico, non esiste un vero caso di test ma qualcosa a cui stavo pensando prima.
L'esempio di DI sottostante va bene, tuttavia è preferibile che le classi concrete vengano mantenute nella root della composizione e non sparse in un'applicazione. C'è un modo per ottenerlo senza un contenitore, o è un po 'un inseguimento selvaggio e contenitori sono necessari se si vuole raggiungere questo obiettivo?
public class SomeClass
{
public SomeClass:this(new Something())
{}
public SomeClass(ISomething something)
{
//logic here
}
}
// aggiornamento La mia domanda non è una duplicazione di quella collegata. Cercherò di elaborare.
Di solito con DI manuale, avrei un costruttore senza parametri come mostrato nell'esempio di codice, che chiama se stesso passando in una classe concreta. In realtà dovrebbe esserci una root di composizione che gestisce ciò che viene passato nei parametri dell'interfaccia e non un concreto definito per ogni classe con un secondo costruttore.
Per le piccole app di console, ecc. è gestibile poiché Main è la tua root di composizione e dove tutto viene eseguito. Tuttavia, su un'app mvc asp.net, ad esempio, questo diventa più complesso. Mi stavo chiedendo quali soluzioni avrebbero potuto provare altre persone.