Negli ultimi mesi, complice anche la querelle "PI or not" portata alla luce da "vorrei ma non posso (ancora)" Entity Framework, ho ulteriormente riflettuto sul valore di un Domain Model agnostico alla persistenza ed ho concluso che PI non basta. Quello che "voglio" è un DM agnostico alla infrastruttura: non voglio PI, non mi basta. Voglio POCO, ma sembra che sia... Troppo <g> (interessante gioco di parole)
Detta "seriamente", vorrei poter modellare un DM concentrandomi sulla soddisfazione dei requisiti "business" (DDD anyone?), ed avere uno stack tecnologico in grado di "appiccicare" in qualche modo il codice necessario alla infrastruttura. Tanto per fare un esempio pratico, vorrei poter evitare di *sporcare* il mio DM implementando INotifyPropertyChanged "solo" perchè così alcuni scenari diventano + comodi da implementare. Un approccio già praticabile sarebbe quello basato sulla generazione dinamica dei proxy unita all'uso dei mixin (a proposito, perchè MS non ne parla più?). Per intenderci, con Castle.DinamicProxy2 si potrebbe impostare così:
ProxyGenerator gen = new ProxyGenerator();
ProxyGenerationOptions options = new ProxyGenerationOptions();
options.AddMixinInstance((INotifyPropertyChanged) new INotifyPropertyChangedImplementation());
Product proxy = (Product)gen.CreateClassProxy(typeof(Product), new Type[] {typeof(INotifyPropertyChanged)}, options, new InvokeInterceptor());
return proxy;
In questo scenario, INotifyPropertyChangedImplementation potrebbe usare una hashtable/dictionary per implementare una strategia genericamente valida. Una implementazione di questo tipo, pur soffrendo dell'overhead necessario alla generazione dei proxy, sarebbe sufficiente nella maggior parte dei casi. Un'altra opzione che sto indagando si basa invece sulla code generation a compile time: probabilmente basterebbe una "custom action" per msbuild, e se fossi MS indagherei seriamente in tal senso.
Ciò di cui sono sicuro è che l'esigenza di un DM "infrastructre agnostic" sia fondamentale: su Linq 2 SQL pende una spada di Damocle e Entity Framework è, negli interessi di MS, il perno della propria strategia MDD. Già sappiamo che le entità gestite da EF saranno recepite (per esempio) dai Reporting Services di SQL Server, quindi è importante evitare sin da subito di avere un DM all'interno del quale ogni framework/sottosistema infili il proprio "ciarpame": il DM è "business", e tale dovrebbe rimanere.
posted @ martedì 29 luglio 2008 15:48