Tutoriel de connexion SQL C#: Dapper + Base de données SQL Server expliquée

Tim Corey

1h 15m 23s

Dans la leçon 10 de la série " C# App Start to Finish " de Tim Corey, Tim explique comment connecter une application C# à une base de données SQL Server en utilisant Dapper. Dans la leçon précédente, l'application utilisait une couche d'accès aux données fausse qui prétendait seulement communiquer avec SQL. Dans cette vidéo, Tim remplace ce code de remplacement par une logique de connexion SQL réelle et montre comment il établit une vraie connexion à la base de données d'une manière propre, évolutive et facile à maintenir.

Cet article décompose les concepts clés que Tim aborde et les explique de manière compréhensible même si vous êtes novice en connexion C# SQL ou SQL Server.

Configuration et nettoyage du projet

Tim commence par examiner la structure de la solution et confirme les changements effectués dans la leçon précédente. Dans Program.cs, il explique qu'il a ajouté du code pour se connecter à la fois aux bases de données SQL Server et de fichiers texte, et a changé le formulaire de démarrage par le formulaire " Create Prize " pour qu'il puisse tester la connexion à la base de données immédiatement.

Il nettoie ensuite la structure du projet en créant deux dossiers :

• Modèles

• DataAccess

Il souligne que cela n'affecte pas la fonctionnalité du code source, mais cela aide à l'organisation. Lorsque vous revenez à un projet plus tard, une structure propre et une nomenclature cohérente rendent beaucoup plus facile l'entretien et l'extension.

Pourquoi Dapper ?

Tim explique qu'il utilisera Dapper comme ORM (Object-Relational Mapper) pour les connexions SQL. Dapper se situe entre les commandes SQL brutes et les ORM de plus haut niveau comme Entity Framework.

Tim préfère Dapper parce qu'il est :

• Presque aussi rapide que ADO.NET brut

• Plus simple que Entity Framework

• Évite la complexité inutile et le lourd code standard

Il mentionne que Entity Framework peut être plus lent et plus lourd, surtout pour les petites applications. Pour son projet, Dapper offre le bon équilibre entre performance et simplicité.

Installation de Dapper

Tim démontre l'installation de Dapper à travers le Package Manager NuGet dans Visual Studio. Après l'installation, Dapper apparaît dans les références du projet, et le code de connexion SQL devient clair et lisible.

Ajout de la chaîne de connexion

Pour utiliser Dapper, vous avez besoin d'une chaîne de connexion. Tim l'ajoute au fichier app.config du projet UI, et non du projet bibliothèque, car la bibliothèque est une DLL et n'a pas sa propre configuration.

La chaîne de connexion comprend :

• Source de données (nom du serveur ou nom de domaine de la machine)

• Catalogue initial (nom de la base de données)

• Sécurité intégrée (authentification Windows)

• Délai de connexion

• ID utilisateur et mot de passe (si vous n'utilisez pas l'authentification Windows)

Dans l'exemple de Tim, il utilise une connexion de confiance, c'est-à-dire une authentification Windows :

Data Source=SQL2016;Initial Catalog=Tournaments;Integrated Security=True;

Data Source=SQL2016;Initial Catalog=Tournaments;Integrated Security=True;

Il souligne que cela évite de stocker les identifiants d'utilisateur SQL Server dans le fichier.

GlobalConfig : Récupérer la chaîne de connexion

Pour récupérer la chaîne de connexion, Tim ajoute une méthode dans GlobalConfig :

public static string GetConnectionString(string name)
{
    return ConfigurationManager.ConnectionStrings[name].ConnectionString;
}

public static string GetConnectionString(string name)
{
    return ConfigurationManager.ConnectionStrings[name].ConnectionString;
}

Cette méthode récupère la chaîne de connexion du fichier de config et la renvoie. Tim ajoute également la référence requise System.Configuration.

Création de la connexion SQL

Tim supprime le code de substitution et crée une vraie SqlConnection en utilisant :

using (IDbConnection connection = new SqlConnection(
    GlobalConfig.GetConnectionString("tournaments")))
{
    // Logique SQL ici
}

using (IDbConnection connection = new SqlConnection(
    GlobalConfig.GetConnectionString("tournaments")))
{
    // Logique SQL ici
}

Il utilise une interface IDbConnection pour pouvoir échanger les types de bases de données (SQL ou fichier texte) sans changer le code principal.

Le bloc using est important car il garantit que la connexion est automatiquement fermée quand le code sort du bloc. Cela évite les connexions ouvertes qui peuvent épuiser le pool de connexions ou provoquer des erreurs sur le serveur de base de données.

Création de la procédure stockée

Au lieu d'écrire du SQL brut dans C#, Tim utilise une procédure stockée. Cela garde la logique SQL dans la base de données et réduit les risques comme les injections SQL.

Il crée une procédure stockée nommée :

dbo.SP_Prizes_Insert

dbo.SP_Prizes_Insert

Cette procédure prend des paramètres correspondant à la table de prix :

• @PlaceNumber

• @PlaceName

• @PrizeAmount

• @PrizePercentage

• @ID (sortie)

Le paramètre de sortie renvoie l'ID nouvellement généré en utilisant :

SELECT @ID = SCOPE_IDENTITY()

SELECT @ID = SCOPE_IDENTITY()

Cela garantit que le nouvel ID d'enregistrement est renvoyé à l'application C#.

Paramètres dynamiques dans Dapper

De retour dans C#, Tim utilise les DynamicParameters de Dapper pour envoyer les paramètres à la procédure stockée :

var p = new DynamicParameters();
p.Add("@PlaceNumber", model.PlaceNumber);
p.Add("@PlaceName", model.PlaceName);
p.Add("@PrizeAmount", model.PrizeAmount);
p.Add("@PrizePercentage", model.PrizePercentage);
p.Add("@ID", 0, dbType: DbType.Int32, direction: ParameterDirection.Output);

var p = new DynamicParameters();
p.Add("@PlaceNumber", model.PlaceNumber);
p.Add("@PlaceName", model.PlaceName);
p.Add("@PrizeAmount", model.PrizeAmount);
p.Add("@PrizePercentage", model.PrizePercentage);
p.Add("@ID", 0, dbType: DbType.Int32, direction: ParameterDirection.Output);

ID est marqué comme Sortie, et Dapper gère le mappage des paramètres.

Exécution de la procédure stockée

Il exécute la procédure stockée :

connection.Execute("dbo.SP_Prizes_Insert", p, commandType: CommandType.StoredProcedure);

connection.Execute("dbo.SP_Prizes_Insert", p, commandType: CommandType.StoredProcedure);

Execute est utilisé parce qu'il effectue une insertion et ne retourne pas de lignes comme une instruction SELECT.

Après l'exécution, le code récupère l'ID :

model.ID = p.Get<int>("@ID");
return model;

model.ID = p.Get<int>("@ID");
return model;

Tests et résultats

Tim exécute l'application, remplit le formulaire et clique sur Créer un prix. Les données sont insérées dans la base de données SQL Server avec succès. Il teste les deux :

• Montant de prix

• Pourcentage de prix

Les deux fonctionnent, prouvant que la connexion à la base de données et la procédure stockée fonctionnent correctement.

Défi de conception : Plusieurs connecteurs de données (1:01:50)

Tim souligne un problème de conception : utiliser simultanément les connecteurs de fichiers SQL et texte provoque des ID incohérents.

Il modifie donc le design pour qu'un seul connecteur fonctionne à la fois. Il ajoute une enum :

DatabaseType
{
    SQL,
    FichierTexte
}

DatabaseType
{
    SQL,
    FichierTexte
}

Cela garantit que l'application utilise toujours un type de base de données cohérent et empêche le mélange de données de base de données de sources différentes.

Conclusion

La leçon 10 de Tim Corey montre une approche pratique pour connecter une application C# à SQL Server en utilisant Dapper. Il couvre :

• Ajout d'une chaîne de connexion

• Utilisation de SqlConnection

• Ouverture et fermeture sécurisées des connexions

• Utilisation de procédures stockées

• Éviter les injections SQL

• Architecture appropriée pour plusieurs sources de données

Si vous voulez une méthode propre, rapide et maintenable pour connecter C# à une base de données SQL Server, cette leçon est un guide parfait.