Non posso che concordare sul discorso Persistence Ignorance fatto pìù volte da Andrea sull'entity framework.
Con altrettanta convinzione affermo però che la completa ignoranza dall'infrastruttura è utopica in scenari reali:
- INotifiyPropertyChanged / INotifiyPropertyChanging ha un costo neppure tanto basso quando è implementato negli oggetti a causa del raising degli eventi. Nella RafCollection avevo scritto INotifiyPropertyChanging ben prima che il framework la introducesse ma sono tornato indietro sfruttando la INotifiyPropertyChanged con parametro null per motivi di performance.
Se penso di usare addirittura un proxy, i valori di performance si alzano vertiginosamente.
- IEditableObject è inerentemente compito dell'entity in quanto gestisce la transazionalità dello stato dell'entity stessa. Questa interfaccia garantisce la coerenza dello stato dell'oggetto quando vengono effettuate modifiche a più proprietà.
- Cloning. Nessuna interfaccia qui per il noto articolo di Brad Abrams. Ma non c'è dubbio che il clone di un oggetto è molto più efficiente se fatto su membri *privati*.
Esempio: Il datetime mantiene un intero a 64 bit. Se io per clonarlo copio tutte le proprietà (giorno, mese, anno, ...) invece di duplicare il valore a 64 bit sto facendo un pessimo lavoro.
Ricordiamoci che non tutte le entity sono fatte di fields 1:1 con le proprietà e una strategia come POCO la si implementa per tutte le entity o nessuna.
- ISerializable / IXmlSerializable. E qui faccio veramente fatica a vedere un proxy che possa risolvermi questa situazione in modo anche lontanamente decente. Il serializzatore Xml tra le altre cose genera al volo con CodeDom il codice per generare una serializzazione performante.
Io mi sono scritto un serializzatore Xml che fa le stesse cose di quello standard ma le performance sono ben lontane da quelle ottenute grazie a CodeDom.
Poi arriviamo a motivazioni più pratiche. Il costo di creazione e manutenzione dei proxy e del codice che serve a fare quelle stesse cose (ma dall'esterno dell'entity) non è poco: maggiore complessità e ciclo di vita più lungo del software.
BTW, come ho detto ai Community Days, mi stupisce che i framework IoC e il neonato MEF lavorino ancora così tanto di reflection invece di sana generazione di codice adhoc a *design* time.
E una volta che fosse possibile trovare il compromesso e arrivare finalmente ad una totale agnosticità del domain model, che ci guadagno? È tutto scritto in C#, dipende tutto dal framework, da un CLR all'altro certe classi potrebbero diventare obsolete, ...
Insomma *IMHO* bisogna arrendersi al fatto che tutto quello che scriviamo è legato alla tecnologie che usa. Questo non toglie che questo vincolo possa permetterci il cross-platform (vedi Mono) ma non certo l'universalità.
Urka, una volta che non sono daccordo con Il Presidente, adesso rischio dei perdere i gradi 