Dificulté:

Passage du relationnel à l'objet

Dans tous les projets du BTS en langage objet, le plus dur est sans doute le passage du monde relationnel de la base de données vers le monde objet des langages de programmation.

Le principe de base est assez simple à comprendre. Vous avez au niveau de votre base une table Adhérent contenant les noms et prénoms de chaque adhérent cette table devra être transformée en liste d’objets Adherent au niveau C#.

Dans le cas les plus simples cela n’est pas trop difficile par contre si vous avez des requêtes complexes avec beaucoup de jointures cela n’est pas simple du tout.

C’est malheureux à dire mais c’est la grande difficulté des projets objet en BTS. La majorité du code écrit sert à la transformation relationnelle vers l’objet. C’est la partie la plus besogneuse il y a beaucoup de code assez redondant.


Quelles sont les solutions :

Solution 1 : La moins « présentable », vous faites de la fausse programmation objet. Vous placez vos requêtes directement au niveau des formulaires de présentation, vous n’avez même pas besoin de créer des classes, vous gérez des chaînes et des entiers. Cette solution ne sera pas étudiée.

Solution 2 : Active Record Pattern

Voici la définition en anglais par le créateur du pattern (un pattern est un morceau de code) : Martin Fowler

Active record

L’Active Record Pattern est la façon la plus simple de passer du monde relationnel au monde objet.

Pour chaque table de votre base vous allez créer une classe correspondante.

Par exemple pour la table Adhérent vous allez créer une classe Adhérent.


Que va contenir la classe adhérent ?

Les champs seront ceux de la table adhérent (nom, prénom, etc..). Il y a aura plusieurs méthodes : lire, modifier, insérer, supprimer. Ces méthodes contiennent les requêtes SQL pour s’interfacer avec la base de données. Vous pouvez aussi avoir d’autres méthodes plus spécifiques à l’adhérent (CalculFinAdhésion par exemple).

Avantage : Assez facile à réaliser

Désavantage : Ne convient pas si vous avez un grand nombre de tables. On ne respecte pas trop les principes de l’objet qui veut qu’une classe ne fasse qu’une seule chose.


Solution 3 Data Mapper Pattern

Un autre pattern créé par Martin Fowler.

Active record

Dans ce pattern on va découpler la partie SQL et la classe métier. Toutes les requêtes SQL seront placées dans un répertoire souvent appelé « Data Access Layer » (DAL).

Par exemple pour la table Adhérent vous allez créer la classe Adherent et la classe AdherentDB (vous pouvez choisir un autre nom).

La classe Adherent va contenir tous les champs de la table adhérent et les méthodes métier (CalculFinAdhésion par exemple).

La classe AdherentDB va contenir toutes les méthodes pour s’interfacer avec la base de données : lire, modifier, insérer, supprimer.


Avantage. Votre logiciel est mieux organisé, vous pouvez modifier la partie SQL sans toucher aux classe métier. On contrôle les requêtes SQL.

Désavantage. Plus de travail et du travail très répétitif.


Solution 4 : Entity Framework.

Le travail de passage du relationnel à l’objet est très très fastidieux. Les informaticiens ont conçu des outils pour vous faciliter la tâche.

Microsoft a développé une solution qui s’appelle Entity Framework. En simplifiant vous allez dire à l’outil les tables que vous utilisez et l’outil générera automatiquement les classes métiers.

Vous n’aurez plus de requêtes SQL à écrire. Vous allez modifiez vos listes d’objets et Entity Framework générera lui-même les requêtes SQL pour mettre à jour les tables.


Avantage : Assez simple d’utilisation et énorme réduction du travail à produire.

Désavantage : Cela n’est pas si simple, si vous voulez faire des requêtes il faut passer par un langage de requête (LINQ). Les requêtes simples ne sont pas difficiles à réaliser mais les GROUP BY ne sont pas faciles avec LINQ.