Créez-vous des classes pour gérer les "entités" des applications pilotées par les données?

Question

Je suis un débutant et lorsque vous créez des applications de base de données, je crée toujours mes formulaires et y place tout le code et les liens. Au lieu d'avoir des tableaux et des listes contenant des informations, j'ai apporté des modifications à la base de données directement. Maintenant que j'ai un peu évolué, disons que j'ai vendu des widgets aux clients et gardé les informations sur les ventes 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 programmer les applications de base de données?

Answer 1

Oui. Vous souhaitez examiner la programmation n-tier. Fondamentalement, vous n'autorisez l'accès frontal (couche de présentation) qu'à votre bibliothèque de classes (couche de gestion). Votre bibliothèque de classes accède alors à votre base de données. Cela vous donne une solution moins étroitement couplée, et permet un code plus maintenable. En outre, en introduisant des niveaux, vous autorisez des modifications à votre base de données sans avoir besoin de réécrire le code dans votre interface, tant que l'interface avec le Business Layer n'a pas besoin d'être modifiée.

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

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

Answer 2

Oui. Vous souhaitez examiner de près Object-Relational Mapping.

Vos entités métier 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 est que si la structure de votre base de données change, votre couche de présentation doit changer, et à long terme, cela a tendance à causer 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 grossière est ici aux marchés; quand vous allez au magasin acheter une miche de pain, vous n'avez pas besoin de savoir comment cultiver le blé; Tout ce que vous devez savoir, c'est que vous avez de l'argent, et 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 il faut planter le blé, ou comment enlever la balle, ou tout autre chose, parce que la couche de support prend soin de cela pour vous. De même, l'agriculteur n'a pas besoin de savoir comment vendre du pain à tout un tas de gens, ni même comment faire du pain; Tout ce qu'il a à faire, c'est savoir cultiver du 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. Par exemple, disons que vous vendez des widgets sur votre site. Au lieu d'avoir votre code de présentation interroger la base de données pour les widgets et l'afficher, vous avez un objet métier qui gère vos widgets.De cette façon, votre objet métier doit connaître la structure de votre base de données, mais votre couche de présentation doit uniquement savoir comment demander à votre objet métier une liste de widgets à afficher. Plus important encore, dans votre objet métier, vous pouvez placer les règles qui doivent être invoquées lorsque certaines choses se produisent. Ainsi, au lieu de votre couche de présentation apportant directement des modifications à la base de données pour l'inventaire et les commandes lorsqu'une commande est passée, votre objet métier sait comment apporter les modifications et les tables à modifier lorsque votre couche de présentation demande une vente. De cette manière, vous séparez l'affichage de vos informations de la persistance et de la logique sous-jacentes au site Web. Ce qui est impliqué est 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 que vos objets métier fourniront. Ensuite, vous implémentez vos objets métier en fonction de ces exigences. ces objets métier sont ceux où vous mettez la connaissance de la structure de la base de données et de votre logique métier spécifique ("quand A arrive, fais B puis C", etc.).

Cela semble beaucoup de travail supplémentaire au début, mais ça en vaut vraiment la peine.