Beyond Persistence Ignorance: *real* POCO

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

Print

Comments on this entry:

# re: Beyond Persistence Ignorance: *real* POCO

Left by DinoE at 29/07/2008 16:23
Gravatar
Non avevo mai capito bene perche' EF dovesse per forza essere POCO/PI. Sono arrivato persino a sostenerlo con alcuni PM solo perché me lo aveva giurato Andrea :)
Poi magicamente in una domenica d'estate arrosto sul balcone a scrivere il cap 6 del libro vedo la luce. EF *deve* essere completamente agnostico ad ogni forma di infrastruttura *proprio* perché MS lo vuole essere qualcosa di piu di un semplice (si fa per dire) O/RM. Che poi paradossalmente la mancanza di POCO si giustifica ufficialmente proprio col fatto che EF non è un semplice O/RM. (E quindi chissenefrega di quello che fanno gli altri ...)
Come mi disse Don Box, "it's all perspective" :)

# re: Beyond Persistence Ignorance: *real* POCO

Left by Matteo Baglini at 29/07/2008 18:50
Gravatar
Io ho parzialmente risolto il problema di INotifyPropertyChanged con i mixin. Dico parzialmente perchè il framework di per se non conosce i mixin quindi è stato scritto "bloccandone" l'uso. E' da una vita che voglio fare un post su questa cosa ma il tempo è sempre li a disturbare.

# [OT] a POCO a POCO

Left by DDL at 31/07/2008 02:17
Gravatar
[OT] a POCO a POCO

# re: Beyond Persistence Ignorance: *real* POCO

Left by Gian MAria at 31/07/2008 15:21
Gravatar
Per quanto riguarda interfacce tipo la INotifyPropertyChanged, tipiche dell'interfaccia il problema viene risolto con i DTO. Io tendo a non passare gli oggetti di dominio in giro, mi piace metterci un servizio e pasasre DTo, i quali possono implementare quello che ti pare. Può essere una soluzione parziale.

Dynamic proxy è carino lo avevo usato, un esempio lo trovi anche sul sorgenti di rhino moks che usa proprio dynamicproxy per i mock (almeno le versioni precedenti di rhino).

Se ti interessa ho invece un po di codice scritto (la notte per un periodo non sapevo che fare) completamente con reflection.emit, per cui generazione di codice direttamente senza nessuna libreria.

Secondo me cmq la cosa migliore sarebbe avere dei designer su visual studio che ti permettano di generare direttamente il codice di tali classi, invece di fare generazione dinamica, in questo modo l'utilizzatore grazie alle classi parziali può comunque modificarli etc etc.

Che gli oggetti di dominio debbano esser il più agnostici possible dall'infrastruttura comunque è il nocciolo fondamentale.

Alk.

# re: Beyond Persistence Ignorance: *real* POCO

Left by Raffaele Rialdi at 31/07/2008 22:54
Gravatar
Alk i DSL sono favolosi ma sono "Domain Specific" by design.
Questo significa che vanno bene quando sono verticalizzati ad una specifica realtà verticale ma per definizione in situazioni generali forniscono un aiuto molto relativo.
Più imponi regole, meglio lavora il DSL e meno fatica l'utente. Ma quelle regole vanno a braccetto con quello specifico business.
La generazione del codice con DSL è quello che fa saltare una azienda da produzione artigianale (come lo è anche MS) a quella industriale. Nella artigianale l'impatto di ogni singolo dev può fare la differenza tra disastro e e successo. In quella industriale l'impatto è minimale perché il dev usa un DSL che ha dei vincoli molto rigidi. Ma questi vincoli *devono* esserci.

# re: Beyond Persistence Ignorance: *real* POCO

Left by Gian MAria at 04/08/2008 15:14
Gravatar
Cmq, DynamicProxy è carino, ma forse per queste cose piccole conviene fare tutto a mano, se vai al mio post http://www.nablasoft.com/alkampfer/index.php/2008/08/04/implement-inotifypropertychanged-with-dynamic-code-generation/

trovi una possibile implementazione, è fatta alla svelta in un oretta scarsa (cavolo era troppo tempo che non usavo reflection emit :D)

alk.

# Mixin, POCO e INotifyPropertyChanged mito o realt

Left by Invest in people before investing in tools at 07/08/2008 02:54
Gravatar
Mixin, POCO e INotifyPropertyChanged mito o realt

# Preoccuparsi di POCO

Left by ExternalBlogs at 20/10/2008 15:45
Gravatar
Ho appena letto un paio di post, uno di Andrea ed uno di Raf , sul domain model e sulla effettiva necessità

Your comment:



 (will not be displayed)


 
 
 
Please add 6 and 4 and type the answer here:
 

Live Comment Preview:

 
«dicembre»
domlunmarmergiovensab
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234