2011-08-29 22 views
5

Recientemente han comenzado a evaluar Dapper como un reemplazo potencial para EF, ya que no estaba demasiado contento con el SQL que se estaba generando y quería más control sobre él. Tengo una pregunta sobre el mapeo de un objeto complejo en mi modelo de dominio. Supongamos que tengo un objeto llamado Proveedor, el Proveedor puede contener varias propiedades de tipo IEnumerable a las que solo se debe acceder yendo a través del objeto proveedor principal (es decir, la raíz agregada). He visto publicaciones similares que explicaron utilizando el método de extensión QueryMultiple y un método de extensión de mapa, pero me preguntaba cómo si quisiera escribir un método que devuelva todo el gráfico de objetos ansiosamente cargado, si Dapper pudiera hacerlo de una sola vez o si era necesario hacerlo por partes. A modo de ejemplo, digamos que mi objeto parecía algo como lo siguiente:Dapper Objeto correcta/balasto Mapeo

public AggregateRoot 
     { 
      public int Id {get;set;} 
      ...//simple properties 
      public IEnumerable<Foo> Foos 
      public IEnumerable<Bar> Bars 
      public IEnumerable<FooBar> FooBars 
      public SomeOtherEntity Entity 
      ... 
     } 

¿Hay una manera sencilla de poblar todo el gráfico de objetos utilizando Dapper?

+0

va a tener que construir algunas extensiones manuales para esto, no hay un método incorporado para el descubrimiento de gráficos y la generación automática de SQL –

+0

Gracias por su respuesta Sam, ¿qué pasa con una solución que no es automática sino que usa un SQL ¿consulta? ¿Es eso posible? Además, ¿cómo se maneja esto en SO, si es que lo hace? ¿O se generan consultas separadas para manejar relaciones de este tipo y complejidad? – mreyeros

+0

Buenas tardes Sam, solo otra pregunta rápida Me di cuenta de que en el método Query puedo pasar hasta 5 objetos usando una de las sobrecargas de métodos. ¿Se puede usar este método para generar lo que estoy tratando de hacer aquí, o estoy malinterpretando su uso? – mreyeros

Respuesta

7

Tengo una situación similar. Hice mi retorno sql plano, para que regresen todos los sub objetos. Luego uso la consulta <> para mapear el conjunto completo. No estoy seguro de lo grande que son tus sets.

Así que algo como esto:

var cnn = sqlconnection(); 

var results = cnn.Query<AggregateRoot,Foo,Bars,FooBar,someOtherEntity,AggregateRoot>("sqlsomething" 
       (ar,f,b,fb,soe)=>{ 
        ar.Foo = f; 
        ar.Bars = b; 
        ar.FooBar = fb; 
        ar.someotherentity = soe; 
        return ar; 

       },.....,spliton:"").FirstOrDefault(); 

Así que el último objeto de la etiqueta de consulta es el objeto de retorno. Para el SplitOn, debe pensar en el retorno como una matriz plana a través de la cual se ejecutará la asignación. Escogería el primer valor de retorno para cada nuevo objeto para que el nuevo mapeo comenzara allí.

ejemplo:

select ID,fooid, foo1,foo2,BarName,barsomething,foobarid foobaritem1,foobaritem2 from blah 

El spliton sería "ID, fooid, BarName, foobarid". A medida que se ejecutó en el conjunto de resultados, asignará las propiedades que puede encontrar en cada objeto.

espero que esto ayude, y que el conjunto de retorno no es demasiado grande para volver plana.

+0

Excelente Arnej65, eso definitivamente me ayudará mucho. – mreyeros

+0

¿Esto también es posible cuando la consulta está en procedimiento almacenado (por lo que básicamente se llama a procedimientos almacenados pasando argumentos)? –

+1

@KrzysztofBranicki Sí. En mi caso, había almacenado procedimientos que consultaban todos los datos necesarios y los devolvía en una salida plana. – Arnej65