Entity Framework CTP5 - Lectura de múltiples conjuntos de registros de un procedimiento almacenado

Question

En EF4, esto no fue posible. O bien tuvo que degradarse a ADO.NET clásico (DataReader), usar ObjectContext.Translate o utilizar el proyecto EFExtensions.

¿Se ha implementado esto de fábrica en EF CTP5?

Si no, ¿cuál es la forma recomendada de hacerlo?

¿Tenemos que emitir el DbContext<T> como IObjectContextAdapter y acceder al subyacente ObjectContext para llegar a este método?

¿Alguien me puede señalar un buen artículo sobre cómo hacer esto con EF CTP5?

Answer 1

Así que me dio este trabajo, esto es lo que tengo:

internal SomeInternalPOCOWrapper FindXXX(string xxx) 
{ 
    Condition.Requires(xxx).IsNotNullOrEmpty(); 

    var someInternalPokey = new SomeInternalPOCOWrapper(); 
    var ctx = (this as IObjectContextAdapter).ObjectContext; 

    var con = new SqlConnection("xxxxx"); 
    { 
     con.Open(); 
     DbCommand cmd = con.CreateCommand(); 
     cmd.CommandText = "exec dbo.usp_XXX @xxxx"; 
     cmd.Parameters.Add(new SqlParameter("xxxx", xxx)); 

     using (var rdr = cmd.ExecuteReader()) 
     { 
      // -- RESULT SET #1 
      someInternalPokey.Prop1 = ctx.Translate<InternalPoco1>(rdr); 

      // -- RESULT SET #2 
      rdr.NextResult(); 
      someInternalPokey.Prop2 = ctx.Translate<InternalPoco2>(rdr); 

      // -- RESULT SET #3 
      rdr.NextResult(); 
      someInternalPokey.Prop3 = ctx.Translate<InternalPoco3>(rdr); 

      // RESULT SET #4 
      rdr.NextResult(); 
      someInternalPokey.Prop4 = ctx.Translate<InternalPoco4>(rdr); 
     } 
     con.Close(); 
    } 

    return someInternalPokey; 
} 

Esencialmente, es básicamente como ADO.NET clásico. Leyó el DbReader, avanzó al siguiente conjunto de resultados, etc.

Pero al menos tenemos el método Translate que aparentemente se mueve de izquierda a derecha entre los campos del conjunto de resultados y la entidad suministrada.

Tenga en cuenta que el método es interno.

Mi Repositorio llama a este método, luego hidrata el DTO en mis objetos de dominio.

no estoy 100% contento con él por 3 razones:

1. Tenemos a emitir el DbContext como IObjectContextAdapter. El método Translate debe estar en DbContext<T> clase IMO.
2. Tenemos que usar objetos clásicos de ADO.NET. ¿Por qué? Los procedimientos almacenados son deben tener para cualquier ORM. Mi principal queja con EF es la falta del soporte de procedimientos almacenados y esto parece no haber sido rectificado con EF CTP5.
3. Tienes que abrir una nueva conexión Sql. ¿Por qué no puede usar la misma conexión que abrió el Contexto EF?

Espero que esto ayude a alguien y envíe un mensaje al equipo de EF. Necesitamos compatibilidad de resultados múltiples para SPROCS fuera de la plataforma. Puede asignar un proceso almacenado a un tipo complejo, entonces ¿por qué no podemos mapear un proceso almacenado a múltiples tipos complejos?