CRUD sur les entités liées utilisant Dapper

.net c# dapper orm

Question

Mon application est le modèle d'entité ci-dessous et utilise 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; }
}

et a un référentiel comme ci-dessous

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

Je suis tombé sur deux scénarios comme ci-dessous

  1. Lors de la récupération de données (entité d'objectif), il doit récupérer tous les objets associés dans la hiérarchie (tous les sous-objectifs, ainsi que les pratiques et les mesures).
  2. Lorsqu'un objectif est enregistré, toutes les données associées doivent être insérées et / ou mises à jour.

Veuillez suggérer qu'il existe une meilleure façon de gérer ces scénarios, à part "parcourir" les collections et écrire des tas de requêtes SQL.

Réponse acceptée

Le meilleur moyen d'effectuer des mises à jour de données par lots volumineuses en SQL à l'aide de Dapper est d'utiliser des requêtes composées.

Vous pouvez récupérer tous vos objets dans une requête sous la forme d'un jeu de résultats multiple, comme ceci:

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

Ensuite, vous écrivez une fonction Dapper qui récupère les objets comme ceci:

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

Vient ensuite la mise à jour de données volumineuses par lots. Vous faites cela via des insertions de paramètres de table (j'ai écrit un article à ce sujet ici: http://www.altdevblogaday.com/2012/05/16/sql-server-high-performance-inserts/ ). Fondamentalement, vous créez une table pour chaque type de données que vous allez insérer, puis écrivez une procédure qui prend ces tables comme paramètres et les écrit dans la base de données.

C'est une performance extrêmement élevée et à peu près aussi optimisée que possible, et le code n'est pas trop complexe.

Cependant, je dois demander: y a-t-il un sens à garder "sous-objectifs" et tous les autres objets relationnels? Une alternative simple consiste à créer un document XML ou JSON contenant votre objectif et tous ses objets enfants sérialisés dans du texte, et de simplement enregistrer cet objet dans le système de fichiers. C'est incroyablement haute performance, très simple, très extensible et prend très peu de code. Le seul inconvénient est que vous ne pouvez pas écrire une instruction SQL pour parcourir tous les sous-objectifs avec un peu de travail. Considérez cela - cela pourrait valoir la peine d'être pensé;)




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi