georgeduke
Messages postés167Date d'inscriptiondimanche 6 février 2005StatutMembreDernière intervention13 avril 2007
-
24 mai 2006 à 18:05
georgeduke
Messages postés167Date d'inscriptiondimanche 6 février 2005StatutMembreDernière intervention13 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
bernie666
Messages postés427Date d'inscriptionmercredi 1 octobre 2003StatutMembreDernière intervention29 janvier 20081 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é"
Nikoui
Messages postés794Date d'inscriptionvendredi 24 septembre 2004StatutMembreDernière intervention19 août 200813 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)
georgeduke
Messages postés167Date d'inscriptiondimanche 6 février 2005StatutMembreDernière intervention13 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
Nikoui
Messages postés794Date d'inscriptionvendredi 24 septembre 2004StatutMembreDernière intervention19 août 200813 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 :)
Vous n’avez pas trouvé la réponse que vous recherchez ?