Domanda semplice: capisco che la serializzazione in C # richiede costruttori predefiniti. Ciò eliminerebbe la possibilità di utilizzare il DI iniettato dal costruttore (che è generalmente lo stile preferito di DI, nella mia lettura [citazione necessaria] ). Quindi è davvero una situazione o, o mi sto perdendo qualcosa?
(Domanda laterale): I contenitori IoC fanno da parte a parte questo compromesso?
Non è possibile de-serializzare un oggetto e anche iniettare una dipendenza a un altro oggetto già esistente in un passo in C #, usando i meccanismi di serializzazione standard. Dovrai invece usare l'iniezione di proprietà, prima costruendo l'oggetto usando il deserializzatore, poi iniettando la dipendenza. Per la maggior parte delle applicazioni del mondo reale, non considero questo un vero inconveniente: se si dispone di una classe del modello di dati serializzabile, che ha anche dipendenze da altre classi di modelli non di dati, è necessario verificare se la classe del modello di dati può avere troppe responsabilità già.
Se ciò ti infastidisce, puoi prendere in considerazione di avvolgere il tuo oggetto serializzabile con una classe decoratore, in cui puoi passare il de-serializer e le dipendenze aggiuntive attraverso il costruttore. Quel wrapper esegue quindi i due passaggi (de-serializzazione dell'inviluppo e dell'iniezione della proprietà) nel suo costruttore.
Sto risolvendo questo problema in questo modo: iniettando fabbriche di dipendenze. In quelle fabbriche, risolvere prima la dipendenza mentre è registrata nel contenitore, quindi "deserializzare" tutti i dati rimanenti: json.net consente di popolare i campi nell'oggetto esistente.
Dato che il codice delle fabbriche segue il codice di cablaggio del contenitore IoC, non penso che l'utilizzo di container.Resolve all'interno della fabbrica violi la regola, che container debba essere utilizzato solo in un punto nel codice: dove avviene il cablaggio.
A partire da ora, sto cercando di rendere automatico questo processo (al contrario di quello che ho provato con questo approccio) usando la riflessione. Sì, non c'è molto di ciò che rimane della deserializzazione di json.net stessa, una parte di essa è sostituita da un codice personalizzato, ma penso, perché preoccuparsi.
Inoltre, qual è stata la tua ultima riflessione / decisione in merito? Dopo aver letto questo post vedo due modi: deserializzare, quindi iniettare; o iniettare, quindi deserializzare (popolare). E continuo a trovare che la mia strada è migliore. Sarò lieto di ascoltare argomenti in opposizione a questo (sto pensando, che il mio modo potrebbe essere migliore per il mio caso, ma non riesco a immaginare vividamente buoni casi alternativi, dove fallisce, solo alcune supposizioni minori)
Leggi altre domande sui tag dependency-injection serialization