Tipi di oggetti
Ai fini della nostra discussione, separiamo i nostri oggetti in tre diversi tipi:
Questi sono gli oggetti che funzionano. Trasferiscono denaro da un conto corrente a un altro, evadono gli ordini e tutte le altre azioni che ci aspettiamo che il software aziendale prenda.
Gli oggetti logici di dominio normalmente non richiedono accessor (getter e setter). Piuttosto, si crea l'oggetto passandogli le dipendenze tramite un costruttore e quindi si manipola l'oggetto tramite i metodi (tell, do ask ask).
Gli oggetti Data Transfer sono pure state; non contengono alcuna logica aziendale. Avranno sempre degli accessor. Possono o non possono avere setter, a seconda che tu li stia scrivendo o meno in modo immutabile . Imposterai i tuoi campi nel costruttore e i loro valori non cambieranno per tutta la vita dell'oggetto, o i tuoi accessori saranno letti / scritti. In pratica, questi oggetti sono in genere mutabili, in modo che un utente possa modificarli.
Visualizza Gli oggetti del modello contengono una rappresentazione di dati visualizzabile / modificabile. Possono contenere logiche di business, generalmente limitate alla convalida dei dati. Un esempio di oggetto View Model potrebbe essere InvoiceViewModel, contenente un oggetto Customer, un oggetto Header di fattura e articoli Line fattura. Gli oggetti View Model contengono sempre accessor.
Quindi l'unico tipo di oggetto che sarà "puro" nel senso che non contiene accessori di campo sarà l'oggetto Logica del Dominio. La serializzazione di tale oggetto salva il suo attuale "stato computazionale", in modo che possa essere recuperato in seguito per completare l'elaborazione. Visualizza Modelli e DTO possono essere serializzati liberamente, ma in pratica i loro dati vengono normalmente salvati in un database.
Serializzazione, dipendenze e accoppiamento
Sebbene sia vero che la serializzazione crea dipendenze, nel senso che è necessario deserializzare su un oggetto compatibile, non necessariamente segue che è necessario modificare la configurazione della serializzazione. I buoni meccanismi di serializzazione sono di uso generale; a loro non importa se si modifica il nome di una proprietà o di un membro, a condizione che possa ancora mappare i valori ai membri. In pratica, ciò significa solo che devi serializzare nuovamente l'istanza dell'oggetto per rendere la rappresentazione della serializzazione (xml, json, qualunque sia) compatibile con il tuo nuovo oggetto; nessuna modifica alla configurazione del serializzatore dovrebbe essere necessaria.
È vero che gli oggetti non dovrebbero preoccuparsi di come sono serializzati. Hai già descritto in un modo che tali preoccupazioni possono essere disaccoppiate dalle classi di dominio: riflessione. Ma il serializzatore dovrebbe essere preoccupato di come serializza e deserializza oggetti; dopotutto, è la sua funzione. Il modo in cui mantieni gli oggetti disaccoppiati dal processo di serializzazione è rendere la serializzazione una funzione generica , in grado di funzionare su tutti i tipi di oggetto.
Una delle cose su cui le persone si confondono è che il disaccoppiamento deve avvenire in entrambe le direzioni. Non è così; deve solo funzionare in direzione one . In pratica, non puoi mai disaccoppiare completamente; c'è sempre un accoppiamento alcuni . L'obiettivo di un accoppiamento lento è facilitare la manutenzione del codice, non rimuovere tutte le dipendenze.