E' un pò che manco dal blog, ma spero che d'ora in poi riuscirò a fare post con più continuità visto l'avvicnarsi della RTM di Visual Studio che per me in particolar modo significa la RTM di Entity Framework 4.0.

Durante la stesura del capitolo 11 del libro ho parlato di come customizzare Entity Framework per generare codice diverso da quello di default tramite i template T4, di come customizzare la generazione del database attraverso Workflow e di nuovo i template ed infine come customizzare il designer.

Quest'ultima parte è di particolare interesse. Io faccio un uso molto estensivo delle structured annotations nell'edm. Modificare l'edmx a mano non è certo un problema, ma se posso farlo da designer perchè no? Ecco,  il team di Entity Framework ha sfruttato MEF per permettere l'estensione del designer proprio per venire incontro ad esigenze di questo tipo.

Faccio un esempio. Quando devo persistere una entity che ha come proprietà chiave un Int32, se il valore è zero la marco come nuova tramite AddObject, altrimenti come aggiornata tramite Attach + ChangeObjectState. (NHibernate ha una feature del genere già integrata). Posso fare una cosa del genere scriveno una if secca nel codice ma diciamoci la verità. It Sucks. In alternativa, posso estendere l'EDM aggiungendo alla proprietà chiave il valore da utilizzare come discriminatore per decidere il tipo di operazione (0 per la add, il resto per la attach). Poi posso costruire un Extension Method che prende l'entità da persistere, tramite i metadati verifica la proprietà chiave e verifica quale valore usare per la insert. In questo modo nel codice noi invochiamo l'extension method e poi se la vede lui per tutto il resto.

Tutto bello , ma modificare l'EDM non è semplice a primo acchitto soprattutto per uno sviluppatore alle prime armi. E allora, perchè non fare in modo che quando si seleziona nel designer la proprietà chiave di una entità non si aggiunga una proprietà nella Properties Window che prenda il valore in base al quale fare la AddObject e che poi lo persista automaticamente nell'EDM?

Grazie all'estendibilità del designer possiamo raggiungere il nostro scopo con una classe con circa 20 righe di codice. Basta una classe che implementi un'interfaccia che ha un solo metodo (che potrebbe essere di una riga) il quale ritorna un'istanza di un'altra classe che contiene la proprietà da aggiungere al designer. Il getter ed il setter di questa proprietà lavorano con l'EDM per recuperarne e modificarne i dati direttamente in XML quindi con LINQ to XML il tutto è estremamente banale.

Alla fine della giostra grazie alla customizzazione del designer abbiamo un notevole incremento della produttività mentre disegnamo il nostro modello, ed una semplificazione del codice per via dell'Extension Method che decide da solo come persistere una entità. Quest'argomento è trattato nel mio libro su Entity Framework quindi direi che è un buon motivo per non lasciarselo sfuggire :).

Stay Tuned...