La maggior parte degli esempi che ho visto guardando qualcosa sulla gestione delle dipendenze ha colpito quello che considero il Santo Graal in quanto le uniche dipendenze dalle classi sono le interfacce che il contenitore IOC può iniettare. Naturalmente la maggior parte degli esempi ha essere banale a causa di vincoli temporali a cui è sottoposto il presentatore. Questo è fantastico per il cliente perché non devono preoccuparsi delle lezioni di idratazione, ma è il mondo reale? Ad esempio sto lavorando su una classe ha una varietà di calcoli. Ecco il costruttore:
public OsEarnDetail(IOsMacRateRepository macRates,IRate rate, OsEarnDetailPoco data)
{
_macRates = macRates;
_rate = rate;
_data = data;
}
Come puoi vedere, ho una struttura dati che impedisce a qualsiasi contenitore IOC di essere in grado di idratare automaticamente la classe. Supponi che questa classe abbia una funzione complessa chiamata CalcFoo() . Non devo solo calcolare questo valore quando un record viene recuperato / salvato dal database. I risultati di questo calcolo devono essere visualizzati all'utente come il tipo di una nuova voce (anche prima di essere salvato nel database) e anche ricalcolato se un utente sta modificando uno dei dati principali (ancora prima che sia stato salvato nel Banca dati).
Sono confuso in qualche modo o c'è qualcosa di sbagliato nel modo in cui costruisco le mie lezioni? Penso che sarebbe normale avere scenari in cui è necessario eseguire complesse logiche di business prima ancora che siano stati salvati nel database e quindi è necessario idratare gli oggetti business con una serie di dati che impedirebbero al contenitore IOC di essere in grado di idratare le tue dipendenze.