Créez-vous des classes pour gérer des «entités» pour des applications basées sur les données?

Question

Je suis un débutant et lors de la création d'applications de base de données, je ne fais que créer mes formulaires et y insérer tout le code et toutes les liaisons. Au lieu d'avoir des tableaux et des listes contenant des informations, j'ai directement modifié la base de données.

Maintenant que j'ai un peu évolué, disons que j'ai vendu des widgets à des clients et conservé les informations de vente dans une base de données. Si j’écrivais un programme pour accéder à la base de données, ne voudrais-je pas créer une classe de type "Client" et "Widget" pour travailler avec ces entités?

Si je me trompe, quelle est l'approche appropriée pour la programmation d'applications de base de données?

Answer 1

Oui.

Vous souhaitez examiner la programmation à plusieurs niveaux .

En gros, vous ne vous autorisez que l’accès frontal (couche présentation) à votre bibliothèque de classes (couche métier). Votre bibliothèque de classes accède ensuite à votre base de données.

Cela vous donne une solution moins étroitement couplée et permet un code plus facilement maintenable. De plus, en introduisant des niveaux, vous autorisez des modifications dans votre base de données sans qu'il soit nécessaire de réécrire du code dans votre interface, tant que l'interface avec la couche de gestion n'a pas besoin d'être modifiée.

En ce qui concerne la liaison, si vous utilisez Visual Studio Windows Forms (à partir de 2005), vous devriez pouvoir nous fournir un bindingSource que vous pouvez ensuite utiliser pour lier vos contrôles. Si vous utilisez ASP.NET, votre contrôle doit alors être lié à une liste d'objets sans aucun problème.

Pour ASP.Net, la ObjectDataSource pourrait être utile. . Je ne l'ai pas utilisé moi-même, mais il y a beaucoup d'échantillons sur le Web. Essayez ici ou ici .

Answer 2

Oui.

Vous souhaitez examiner de plus près la Cartographie objet-relationnel .

Vos entités professionnelles réelles sont modélisées par des objets mappés à des tables relationnelles.

Answer 3

Vous ne voulez pas que votre couche de présentation dépende directement de la structure de votre base de données; Le problème, c’est que si la structure de votre base de données change du tout, votre couche de présentation doit changer et, à long terme, cela tend à poser des problèmes. De plus, il existe des problèmes de sécurité liés à l'interaction directe de votre couche de présentation avec votre base de données.

L’analogie approximative ici concerne les marchés; quand vous allez au magasin pour acheter une miche de pain, vous n'avez pas besoin de savoir comment faire pousser du blé; tout ce que vous devez savoir, c'est que vous avez de l'argent, qu'ils ont du pain et qu'ils échangeront une certaine quantité de pain contre une certaine somme d'argent. Vous n'avez pas besoin de savoir à quelle période de l'année planter le blé, ni comment enlever l'ivraie, ni rien de tout cela, car la couche de protection s'occupe de cela pour vous. De même, le fermier n'a pas besoin de savoir vendre le pain à un tas de gens, ni même comment le faire; tout ce qu’il a à faire est de savoir cultiver le blé.

La philosophie de conception moderne vous recommande d'utiliser une couche intermédiaire pour interagir entre votre couche de présentation et votre couche de base de données. c'est là que vous mettez votre logique métier. Ainsi, par exemple, supposons que vous vendiez des widgets sur votre site. Au lieu de demander à votre code de présentation d'interroger la base de données pour les widgets et de l'afficher, vous avez un objet métier qui gère vos widgets. Ainsi, votre objet métier doit savoir quelle est la structure de votre base de données, mais votre couche de présentation doit seulement savoir comment demander à votre objet métier une liste des widgets à afficher. Plus important encore, dans votre objet métier, vous pouvez placer les règles à invoquer lorsque certaines situations se produisent. Ainsi, au lieu que votre couche présentation modifie directement la base de données pour l’inventaire et les commandes lorsqu’une commande est passée, votre objet métier sait comment y apporter les modifications et quelles tables modifier lorsque votre couche présentation demande la vente.

De cette manière, vous séparez l'affichage de vos informations de la persistance et de la logique sous-jacente du site Web. Il s’agit d’une bonne planification. Plus précisément, vous devez déterminer ce que votre site Web fera à un moment donné et ce que cela signifie en termes d'interfaces fournies par vos objets métier. Ensuite, vous implémentez vos objets métier en fonction de ces exigences. Ces objets métier sont les endroits où vous mettez la connaissance de la structure de la base de données et de votre logique métier spécifique ("Lorsque A se produit, exécutez B puis C", etc.).

Cela semble être une charge de travail supplémentaire au début, mais cela en vaut vraiment la peine.