Intérêt des classes métiers ds logiciel de bdd [Résolu]

Signaler
Messages postés
171
Date d'inscription
dimanche 6 février 2005
Statut
Membre
Dernière intervention
13 avril 2007
-
Messages postés
171
Date d'inscription
dimanche 6 février 2005
Statut
Membre
Dernière intervention
13 avril 2007
-
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

Messages postés
427
Date d'inscription
mercredi 1 octobre 2003
Statut
Membre
Dernière intervention
29 janvier 2008
1
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é"
Messages postés
794
Date d'inscription
vendredi 24 septembre 2004
Statut
Membre
Dernière intervention
19 août 2008
9
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)
Messages postés
171
Date d'inscription
dimanche 6 février 2005
Statut
Membre
Dernière intervention
13 avril 2007

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
Messages postés
794
Date d'inscription
vendredi 24 septembre 2004
Statut
Membre
Dernière intervention
19 août 2008
9
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 :)
Messages postés
171
Date d'inscription
dimanche 6 février 2005
Statut
Membre
Dernière intervention
13 avril 2007

Merci ;-)