Design del codice: codice duplicato o buona implementazione

Tratterei semplicemente le classi che verranno serializzate e deserializzate come DTO , e scegli quale utilità metodo che si desidera eseguire la serializzazione / deserializzazione. In questo modo hai solo bisogno di una singola classe per portare le informazioni.

Ogni metodo di utilità può contenere alcuni parametri di validazione, se sei preoccupato per un parametro non valido. Se si desidera mantenere i metodi nel DTO, creare un paio di metodi di fabbrica che accettano un'origine dati di serializzazione e restituiscono un DTO.

L'unica cosa che non fare è avere due classi di modelli solo perché vuoi automatizzarne una nuova, ma manualmente la nuova l'altra con un costruttore forzato. Ciò crea due posti diversi per i tuoi dati e viola il principio della Sorgente unica della verità.

Mantieni semplice, soldato.

Trovo abbastanza fastidioso che molte librerie di serializzazione richiedano costruttori senza parametri.

Con la possibilità di annotare i parametri, in teoria è possibile specificare le associazioni tra i parametri del costruttore e gli elementi di serializzazione, in modo che la libreria di serializzazione possa raccogliere tutti gli elementi necessari e passarli al costruttore dell'oggetto deserializzato. Ahimè, devo ancora imbattersi in una libreria di serializzazione che offre tale funzionalità.

Inoltre, la capacità di serializzare oggetti con costruttori parametrizzati è necessaria anche se non stiamo progettando di parametrizzarli con valori deserializzati; ad esempio, per implementare Iniezione di dipendenza senza ricorrere alla magia come Spring.NET.

Per quanto ne so, il modo in cui la maggior parte delle persone gestisce questo è di avere due gruppi separati di classi, uno per la logica dell'applicazione con cui lavorare e uno solo per la serializzazione.

Si scopre che questo non è male, perché il modello di dati con cui si desidera lavorare nella logica dell'applicazione di solito non è esattamente lo stesso del modello di dati che ha senso persistere.

Ad esempio, è possibile avere la libertà di modificare il modello di dati dell'applicazione mantenendo la compatibilità con i file di serializzazione creati da versioni precedenti del modello dati. Se una serie di classi è tutto ciò che hai, allora nel momento in cui apporti una modifica al tuo modello di dati, tutti i tuoi vecchi dati sono improvvisamente illeggibili. Se si mantiene il modello dei dati dell'applicazione separatamente dal modello dei dati di serializzazione, è possibile avere versioni diverse (contemporaneamente esistenti) del proprio modello di dati di serializzazione da utilizzare con versioni diverse dei file di serializzazione esistenti.

Mantenere questo pragmatico - la creazione di un gran numero di codice duplicato o standardizzato dovrebbe essere un no-go, oltre a reimplementare da solo un meccanismo di serializzazione maturo del framework. Quindi mordere il proiettile e fornire un costruttore senza parametri: questo, in realtà, non risulta essere così brutto come si potrebbe pensare.

È possibile rendere privato il costruttore e fornire un metodo statico all'interno della classe per la deserializzazione, che assicura che l'attributo "costruttore obbligatorio" sia passato nell'oggetto dopo la deserializzazione. Ciò rende almeno improbabile che qualcuno si dimentichi di impostare l'attributo aggiuntivo.

Che dire di due metodi statici nella classe per seralizzare e de serailize. Il parametro è un argomento di questa funzione e viene memorizzato come costante da qualche parte.

Se finisci per avere molti di questi oggetti, crea una classe che ha un elenco di questi. Questo dovrebbe avere la capacità di mettere in relazione i metodi dell'intero elenco. Richiederebbe anche un delegato del filtro e fornirà un nuovo elenco dopo il filtro (non eliminare i dati prima di salvare). Avrebbe anche i due metodi statici. La classe e l'altro parametro sono argomenti.