5

Nella maggior parte dei miei progetti utilizzo la mappatura di NHibernate + Fluent e recentemente ho iniziato a giocare con Dapper per vedere se posso spostare le operazioni di lettura su di esso.Mappatura degli attributi privati ​​delle entità di dominio con Dapper dot net

Seguo l'approccio DDD quindi le mie entità di dominio non hanno setter pubblici. Per esempio:

public class User 
{ 
    private int _id; 
    private string _name; 
    private IList<Car> _carList; 

    protected User(){} // Fluent Mapping 

    public User(string id, string name) 
    { 
     // validation 
     // ... 
     _id = id; 
     _name = name; 
    } 

    public int Id{ get {return _id;} } 
    public string Name { get {return _name;} } 
    public IList<Car> CarList { get {return _carList;}}   
} 

public class Car 
{ 
    private int _id; 
    private string _brand; 

    protected Car(){} // Fluent Mapping 

    public Car(string id, string brand) 
    { 
     // validation 
     // ... 
     _id = id; 
     _brand= brand; 
    } 

    public int Id{ get {return _id;} } 
    public string Brand { get {return _brand;} } 
} 

Con Fluent NHibernate sono in grado di rivelare i membri per la mappatura:

Id(Reveal.Member<User>("_id")).Column("id"); 
Map(Reveal.Member<User>("_name")).Column("name"); 

Esiste un modo per mappare le entità di dominio con Dapper? Se é cosi, come?

+4

Si noti che il IList esposto dalla classe Utente, è un odore DDD proprio come un setter: si dovrebbe esporre un IEnumerable invece, dal momento che tutte le operazioni su un [aggregato] (http://dddcommunity.org/library/ vernon_2011 /) stato dovrebbe essere gestito tramite [comandi] (http://epic.tesio.it/doc/manual/command_query_separation.html) inviato ad esso. –

risposta

8

Un'opzione è creare un set separato di classi di persistenza per lavorare con Dapper; ad esempio: UserRecord e CarRecord. Le classi di record corrisponderanno alla tabella db e verranno incapsulate all'interno del modulo di persistenza. Le query di Dapper verranno eseguite contro queste classi e quindi sarà possibile creare una factory di persistenza separata che riunirà le entità di dominio e le restituirà al client.

piccolo esempio:

 var carRecord = DbConnection.Query<CarRecord>("select * from cars where id = @id", new {id = 1}); 
     var carEntity = CarFactory.Build(carRecord); 

Questo crea un bel separazione e fornisce la flessibilità.

+3

+1 Posso confermare che questa soluzione funziona molto bene per [repository personalizzati] (http://epic.tesio.it/doc/manual/repositories.html#about_custom_repositories). –

+0

Ho pensato a questa soluzione ma visto che questo mi fa scrivere molto più codice mi chiedevo se ci fosse qualche alternativa. Grazie per i tuoi commenti –

+0

@ R2D2: Mi chiedo, come hai implementato? Conosco questo post piuttosto vecchio ma sono bloccato in una situazione simile e sono finito su questo post durante la ricerca. –

Problemi correlati