CRUD en entidades relacionadas que usan Dapper

.net c# dapper orm

Pregunta

Mi aplicación tiene un modelo de entidad como el siguiente y usa Dapper

public class Goal
{
    public string Text { get; set; }
    public List<SubGoal> SubGoals { get; set; }
}

public class SubGoal
{
    public string Text { get; set; }
    public List<Practise> Practices { get; set; }
    public List<Measure> Measures { get; set; }
}

y tiene un repositorio como se muestra a continuación

public interface IGoalPlannerRepository
{
    IEnumerable<Goal> FindAll();
    Goal Get(int id);
    void Save(Goal goal);
}

Me encontré con dos escenarios como a continuación

  1. Al recuperar datos (entidad objetivo), debe recuperar todos los objetos relacionados en la jerarquía (todos los objetivos secundarios junto con las prácticas y medidas)
  2. Cuando se guarda un objetivo, todos los datos relacionados deben insertarse y / o actualizarse

Sugiera que hay una forma mejor de manejar estos escenarios que no sea "recorrer" las colecciones y escribir muchas consultas SQL.

Respuesta aceptada

La mejor forma de hacer grandes actualizaciones de datos por lotes en SQL usando Dapper es con consultas compuestas.

Puede recuperar todos sus objetos en una consulta como un conjunto de resultados múltiples, como este:

CREATE PROCEDURE get_GoalAndAllChildObjects
    @goal_id int
AS
SELECT * FROM goal WHERE goal_id = @goal_id
SELECT * FROM subgoals WHERE goal_id = @goal_id

Luego, escribe una función dapper que recupera los objetos como este:

using (var multi = connection.QueryMultiple("get_GoalAndAllChildObjects", new {goal_id=m_goal_id})) {
    var goal = multi.Read<Goal>();
    var subgoals = multi.Read<SubGoal>();
}

Luego viene la actualización de datos grandes en lotes. Lo haces a través de insertos de parámetros de tabla (escribí un artículo sobre esto aquí: http://www.altdevblogaday.com/2012/05/16/sql-server-high-performance-inserts/ ). Básicamente, crea una tabla para cada tipo de datos que va a insertar, luego escribe un procedimiento que toma esas tablas como parámetros y las escribe en la base de datos.

Este es un rendimiento súper alto y lo más optimizado que puede obtener, además el código no es demasiado complejo.

Sin embargo, necesito preguntar: ¿hay algún punto para mantener los "objetivos intermedios" y todos los demás objetos relacionales? Una alternativa fácil es crear un documento XML o JSON que contenga su objetivo y todos sus objetos secundarios serializados en texto, y simplemente guarde ese objeto en el sistema de archivos. Es un rendimiento increíblemente alto, muy simple, muy extensible y requiere muy poco código. El único inconveniente es que no se puede escribir una instrucción SQL para navegar por todos los objetivos secundarios con un poco de trabajo. Considéralo, podría valer la pena pensar;)



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué