jankyBlog

Si avvicina il meeting nelle marche e c'è ancora qualcuno che non crede che ci saranno le pallavoliste svedesi. Invece viassicuro che io e il crad ve le faremo realmente vedere.

Stavamo pensando di presentare un modello di dominio che funzionasse con NHibernate sia con il file di mapping, sia con gli attributi. L'idea mi era già venuta per il meeting in veneto, ma poi alla fine non ci sono arrivato con i tempi.

in NH infatti si può scrive allo stesso modo sia questo:

public class Persona
{
   public string Nominativo;
}

<class name="Persona" table="Persona">
   <property name="Nominativo"/>
</class>

che questo:

[Class]
public class Persona
{
    [Property]
    public string Nominativo;
}

Qualche considerazione non indifferente

1. Pensiamo ad un Domain Model su un assembly separato rispetto ad un data layer e al Presentation. Decorare con attributi mi impone il fatto di referenziare nell'assembly di Dominio gli assembly del mio ORM. 
   Poco Elegante.
   
2. Se dovessi scrivere delle estensioni del mio ORM, (un custom type persister o un custom entity persister) il posto più giusto dove metterlo sarebbe dunque l'assembly del mio DAL. Ma per usare le estensioni, gli attributi dovrebbero in qualche modo dichiararli/definirli. Il che mi imporrebbe di referenziare nel Domain Model anche il DAL stesso!....anatema! una bella referenza circolare. Ci vorrebbe un altro assembly solo per le estensioni.
   Patetico.
   
3. Non è necessariamente vero che una classe decorata abbia il limite di essere mappata 1 a 1 con una tabella. Dipende dall'ORM. NHibernate e molti altri non hanno questo limite, lo aveva invece DLinq nelle prime versioni (ma la cosa sembra prendere una piega diversa).
   Indifferrente
   
4. Con attributi, una qualsiasi modifica alla struttura del db da riproporre sulla configurazione impone la ricompilazione. Il cambio del file di configurazione impone la ricostruzione della factory, quindi al massimo un riavvio dell'applicazione in produzione. E' una possibilità in piu non avere gli attributi...ma è anche vero che una modifica di un DB se avviene per un cambio di requisito (aggiunta di nuove colonne o altro) imporrebbe cmq del codice nuovo.
   Comodo.
   
5. Informazioni di mappatura tramite attributi, immerse nelle classi di dominio, non mi permettono di usare il dominio, trasversalmente con DAL diversi (magari su DB diversi e Schema diversi).
   Limitante

In pratica non li uso mai, in modo da lasciare il domain layer libero da reference del mio ORM o da informazioni di persistenza di alcun tipo. 

In pratica: un developer con...gli "attributi"...non userebbe mai gli "attributi" con un ORM!...:-)
(ha fatto la battutaaaa....)

Ma se qualcuno su progetti piccoli si vuole fermare alla comodità di mettere attributi piuttosto che scrivere un xml, lo lasceremo d'esempio. Ma anche a quelli mi rivolgo....ma non avete visto NHDomainMapper? :-) 
XML generato al volo, interfaccia grafica con approccio Topdown puro...ect...etc...

NHDomainMapper è l'unico che può battere Chuck Norris.