Una delle soluzioni architetturali che ho imparato ad apprezzare ed utilizzare nel corso degli anni è quella che prevede:

- uno strato Model, contenente una o più entità POCO referenziate tra loro;
- uno strato Repository per l’accesso ai dati;
- uno strato Service;
- uno strato Presentation, che contiene le nostre pagine html/aspx (o le view se sviluppate in asp.net mvc).

Una pratica che vi consiglio caldamente di seguire è di non utilizzare gli oggetti POCO per la loro rappresentazione grafica, ma di affidarvi a dei DTO di appoggio.
In tal senso, oggi ho scoperto un utilissimo metodo fornito da AutoMapper, in sede di creazione della Map tra un oggetto POCO ed un DTO.

1
2

cfg.CreateMap<User, ViewModel.User.dtoUser>()
.ForMember(dest => dest.Property, opt => opt.NullSubstitute("N/A"))

L’utilizzo del metodo NullSubstitute vi consente di associare automaticamente un valore string di default nel caso in cui la proprietà risulti essere NULL. (nel mio caso voglio visualizzare N/A nel caso in cui Property sia NULL).

Consideriamo il caso di un’applicazione n-layered:
- strato di Presentation;
- strato di Business Logic;
- strato DAL per l’accesso ai dati sfruttando Linq to Entity;
- strato dell’ObjectModel.

All’interno di quest’ultimo creiamo un modello sfruttando le potenzialità della nuova versione di Entity Framework 4 (EF4).

Può capitare di imbattersi nel seguente errore in fase di istanziazione dell’ObjectContext e quindi di connessione al db:

Unable to load the specified metadata resource

L’errore, nel mio caso, derivava da una non corretta valorizzazione dell’attributo MetaData dell’oggetto EntityConnectionStringBuilder.

Quando Visual Studio 2010 crea il modello per voi, parte dal presupposto che la stringa di connessione non venga usata in ambiente n-layered. Per questo motivo, la stringa di connessione avrà un aspetto del tipo:

res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl

Il problema si presenta nel momento in cui si cerca di istanziare l’ObjectContext da un altro strato dell’applicazione.

Ciò avviene perchè Res://*/ è un URI che punta alla risorsa nell’assembly corrente. Nel caso in cui, come detto, l’edmx del modello si trovi in un assembly diverso dal codice che si sta usando, res://*/ non riesce a risolvere la risorsa nella posizione corrente.

Basterà quindi specificare l’esatta posizione del Modello edmx:

res://ObjectModel/Model.csdl|res://*/
Model.ssdl|res://ObjectModel/Model.msl

(via stackoverflow)