DataContracts with behavior

Question

Quanto è grave? Ho letto innumerevoli articoli e non ho mai creato DataContracts astratti con un comportamento precedente, ma sembra che così facendo risolverò un problema che mi impedirà di creare fabbriche ovunque per determinare un'implementazione di sottoclasse. La mia domanda è: verrò punito se deciderò di aggiungere un comportamento ai miei contratti di dati? Ovviamente non possono essere consumati e sono lì per eseguire determinate operazioni specifiche per quel tipo di sottoclasse prima di richiamare chiamate di repository e dati sono persistenti. Posso creare classi "Manager" per ogni sottoclasse, ma questo mi riporta alle fabbriche e sto cercando un approccio più polimorfico. Grazie in anticipo.

Answer 1

Perché non è possibile creare il contratto dati (MyDataContract) in modo classico, solo campi dati, nient'altro e quindi derivare la classe di comportamento da esso?

public class BehaviorialClass : MyDataContract 
{ 
..... 
} 

In questo modo, si ha una bella, netta separazione delle preoccupazioni, il vostro contratto di dati non è "inquinato" da comportamenti non può che fare proprio con in ogni caso .....

Marc

Answer 2

Un buon compromesso per mettere il comportamento direttamente nei vostri DataContracts sarebbe definire comportamenti come extension methods nello stesso assembly come i vostri Contratti o un diverso assemblaggio del tutto. Facoltativamente, i metodi di estensione possono essere inseriti in uno spazio dei nomi separato dai contratti per isolare ulteriormente la separazione dei dati e del comportamento.

In questo modo i tuoi contratti vengono mantenuti puliti ma, allo stesso tempo, i clienti .NET dei tuoi contratti avranno un modo semplice per importare funzionalità aggiuntive relative a tali DataContracts.

Answer 3

È possibile aggiungere tutto il comportamento desiderato ai contratti dati. Dovresti documentare chiaramente che il comportamento non sarà visibile ai clienti, altrimenti qualcuno sarà deluso in seguito. Inoltre, documenta il fatto che occorre prestare attenzione a non aggiungere alcun dato dipendente dall'implementazione al contratto dati, dal momento che non è qualcosa che si desidera trasmettere ai client.

Tutto sommato, penso che sarebbe meglio lasciare che i contratti di dati siano contratti di dati e lasciare il comportamento al di fuori di essi.

Answer 4

A un certo punto si vorrà utilizzare MemberwiseClone e implementare le interfacce senza inutili traduzioni di dati intermedi (e ancora peggio, MANUTENZIONE inutile). I metodi di estensione sono per quando non hai letteralmente alcun controllo sulla definizione dell'oggetto ma hai ancora bisogno di fluidità orientata agli oggetti; aggiungono lavoro occupato in qualsiasi altra situazione e distribuiscono definizioni di classe peggiori di C/C++. Oscilla le "tendenze" e fai ciò che funziona per te, potresti scoprire un modello che cambia l'intera partita (come AsyncEnumerator di Jeffrey Richter).