Intérêt des classes métiers ds logiciel de bdd

Résolu
georgeduke Messages postés 167 Date d'inscription dimanche 6 février 2005 Statut Membre Dernière intervention 13 avril 2007 - 24 mai 2006 à 18:05
georgeduke Messages postés 167 Date d'inscription dimanche 6 février 2005 Statut Membre Dernière intervention 13 avril 2007 - 2 juin 2006 à 20:32
Tout petit "sharpeux" que je suis, j'ai du mal à saisir l'utilité de constituer des "classes métiers" dans la réalisation de logiciel de base de données.

Prenons par exemple une appli de gestion commerciale. Je vois dans certaines sources des classes métiers "clients" ou "fournisseurs" ; qui s'autoalimentent des données de la base etc.

Ce qui me perturbe c'est qu'elles instancient et utilisent des variables typées alors que l'on peut aisément rapatrier ces dernieres via une simple requete et un dataset.

Je ne comprends pas ce que peuvent permettre ces classes métiers... Quelqu'un peut m'éclairer sur les grandes lignes ? Merci

5 réponses

bernie666 Messages postés 427 Date d'inscription mercredi 1 octobre 2003 Statut Membre Dernière intervention 29 janvier 2008 1
26 mai 2006 à 22:24
Pour des petites applis avec des petites classes tu peux te permettre de ne pas utiliser de classes métiers ... Mais quand les applis deviennent importantes et que les projets ce multiplies , il est tres interessant d'avoir recours à ces classes pour la "réutilisabilité"
3
Nikoui Messages postés 794 Date d'inscription vendredi 24 septembre 2004 Statut Membre Dernière intervention 19 août 2008 13
29 mai 2006 à 13:46
Voila quelques raison supplémentaires d'utiliser des classes métiers :
- Ton modèle objet peut être différent de ton modèle de données : par exemple, ta classe métier "Fournisseur" est peut être stockée dans 2 ou 3 tables en base, alors que dans la logique "métier", un fournisseur est une entité "distincte"...
- Une base tu ne stocke que les données persistantes, mais tu peux très bien avoir besoin d'autre informations. Exemple bidon, dans ta classe Client tu pourrai avoir une référence vers une session d'achat en ligne... mais tu ne va stocker ca en base.
- En utilisant des classes métier, tu fais de l'objet. Avec un logiciel de base de données (que je suppose relationnel) ce n'est pas le cas : Ton modèle métier objet peut faire apparaitre de l'héritage, de la composition/agrégation, etc.
- etc...

Bref pour résumer, utiliser des classes métier de permet de
- coder en objet (alors que la base ne l'est pas)
- faire abstraction du modèle de données (la facon dont sont stockées les infos en base, les tables etc)
3
georgeduke Messages postés 167 Date d'inscription dimanche 6 février 2005 Statut Membre Dernière intervention 13 avril 2007
30 mai 2006 à 20:03
Merci pour cet éclairage ; du coups ça change pas mal de choses tout ça dans mon approche actuelle du développement.

J'ai tres bien compris ton exemple de la session d'achat pour l'entité "client" qui n'a pas lieu d'etre stockée en base de données. Comme je n'ai pas mis en place de classe métier (comme il n'y a pas eu d'analyse à ce niveau) j'ai stocké ce genre d'information dans une classe qui est chargée de la communication avec la bdd. Un beau chantier quoi...

Deux grosses difficultés semblent se profiler avec ces classes métiers :
- cela demande de la discipline pour coordonner le modele des données avec celui des objets ^^
- cela implique certainement un autre mode de fonctionnement au niveau du databinding avec l'interface graphique

Merci encore pour votre aide
0
Nikoui Messages postés 794 Date d'inscription vendredi 24 septembre 2004 Statut Membre Dernière intervention 19 août 2008 13
30 mai 2006 à 21:02
Tu mets effectivement le doigt là où ca fait mal... il n'y pas de solutions mirable pour "mapping objet/relationnel"... il existe des produit qui automtisent cela, mais avec pas mal de contrainte. L'autre solution est de faire à la main... mais pas très flexible. Bref, bon courage :)
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
georgeduke Messages postés 167 Date d'inscription dimanche 6 février 2005 Statut Membre Dernière intervention 13 avril 2007
2 juin 2006 à 20:32
Merci ;-)
0
Rejoignez-nous