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 12.48

Print

Comments on this entry:

# re: Beyond Persistence Ignorance: *real* POCO

Left by Andrea Saltarello at 29/07/2008 12.58
Gravatar
Marco, con l'ultima codebase che avevo scaricato dal trunk non c'era verso, ma ammetto che nell'ultimo mese non ho avuto modo di approfondire il discorso: venerdi parto per le ferie ed ho troppe attività in sospeso. :-(
Cmq appena rientro (metà agosto) scarico la nightly + aggiornata e vedo di venirne a capo

# re: Beyond Persistence Ignorance: *real* POCO

Left by DinoE at 29/07/2008 13.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 15.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 30/07/2008 23.17
Gravatar
[OT] a POCO a POCO

# re: Beyond Persistence Ignorance: *real* POCO

Left by Gian MAria at 31/07/2008 12.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 Andrea Saltarello at 31/07/2008 12.39
Gravatar
@Gian Maria
1) 100% d'accordo sui DTO ma, come sostengo ormai da anni, il problema quando hai DM composti da *centinaia* di entità è che passi la vita a generare DTO funzionali ai vari casi d'uso. In poche parole, è uno di quei casi dove Visual Studio (o qlche tool, insomma) dovrebbe offrire un vero supporto
2) Il problema non è DynamicProxy, che supporta i agevolmente i mixin. Il "problema" è voler usare i mixin DynamicProxy2, che ha una API decisamente migliore ma che al momento è bacatissimo. Io e "il Crad" stavamo parlando proprio di DynamicProxy2
3) 100% d'accordo anche su code generation: la frase "Un'altra opzione che sto indagando si basa invece sulla code generation a compile time" non è messa lì a caso :-)

# Preoccuparsi di POCO

Left by Alkampfer's Place at 31/07/2008 14.45
Gravatar
Preoccuparsi di POCO

# re: Beyond Persistence Ignorance: *real* POCO

Left by Raffaele Rialdi at 31/07/2008 19.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 12.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 06/08/2008 23.54
Gravatar
Mixin, POCO e INotifyPropertyChanged mito o realt

# Preoccuparsi di POCO

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

# Mixin, POCO e INotifyPropertyChanged mito o realt&#224;?

Left by Invest in people before investing in tools at 20/10/2008 16.48
Gravatar
Dopo aver chiesto ad i CDays2008 a Mauro cosa pensava dei mixin, dopo aver letto i vari post di Andrea

Your comment:



 (will not be displayed)


 
 
 
Please add 6 and 2 and type the answer here:
 

Live Comment Preview:

 
«ottobre»
domlunmarmergiovensab
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345