IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres Discussion :

Objet métier (pourquoi l'annote-t-on?) [N-Tier]


Sujet :

Autres

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    septembre 2010
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2010
    Messages : 7
    Points : 6
    Points
    6
    Par défaut Objet métier (pourquoi l'annote-t-on?)
    Bonsoir,
    J'ai besoin de votre aide pour comprendre avec précision l'architecture logicielle et le découpage en couches.
    Prenons l'exemple d'une application gérant des utilisateurs stockés en BDD (table User avec un champ (id, name, pass)).

    On a besoin d'un objet métier "User" (qui comme son nom l'indique est l'objet qui sera manipulé dans l'application)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public class User{
      int id;
      String name;
      String pass;
    
      +get/set
    }
    Afin de faire persister cet objet on rajoute des annotations JPA pour obtenir finalement :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    @entity
    public class User{
      @Id
      int id;
      String name;
      String pass;
    
      +get/set
    }
    Donc voici enfin ma question, je ne comprends pas pourquoi on a "le droit" d'annoter l'objet métier? En effet, pour moi l'objet métier devrait être indépendant de la manière dont il persiste. Ainsi, si demain, les users ne soient plus seulement en bdd mais aussi stockés ds un fichier Xml. Comment fait-on? On crée un nouvel objet? mais du coup il faut refaire toutes la partie traitement?

    Pour moi il serait plus logique d'avoir un objet métier
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public class User{
      int id;
      String name;
      String pass;
    
      +get/set
    }
    puis d'avoir un objet de type persitent BDD
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public class UserBDD{
      int id;
      String name;
      String pass;
    
      +get/set
    }
    puis un objet
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public class UserXml{
      int id;
      String name;
      String pass;
    
      +get/set
    }
    Rem : Éventuellement, ces objets pourraient ne pas avoir le même nombre d'attributs.

    Puis on rajouterait 2 composants chargés de créer des objets métiers (user). Un transformant des UserXml en user et l'autre des userBdd et user.

    Ainsi toute notre partie traitement n'aurait à subir aucun changement.
    Ex : la fonction métier : findAllUser renverrait des users qu'ils viennent de la bdd ou du xml.

    Etant donné que sur le net tous les exemples font comme ca en quoi mon raisonnement est faux? et surtout comment faire pour gérer des éléments
    pouvant venir de 2 sources différentes?

    D'avance merci pour votre aide.

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    juin 2008
    Messages
    17 532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 17 532
    Points : 30 251
    Points
    30 251
    Par défaut
    Salut,
    Il y a d'un côté la conception et de l'autre la réalisation qui n'a pas nécessairement vocation de réaliser plus que nécessaire.
    et surtout comment faire pour gérer des éléments pouvant venir de 2 sources différentes?
    Pour le coup, il faut retravailler la conception car deux sources différentes peut signifier l'existence d'un enregistrement dans les deux "bases" d'un même individu... Lequel va-t-on lire? mettre à jour?

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  3. #3
    Futur Membre du Club
    Profil pro
    Inscrit en
    septembre 2010
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2010
    Messages : 7
    Points : 6
    Points
    6
    Par défaut
    Pour commencer merci pour cette première réponse.

    Citation Envoyé par wiztricks Voir le message
    Il y a d'un côté la conception et de l'autre la réalisation qui n'a pas nécessairement vocation de réaliser plus que nécessaire.
    - W
    Je suis 100% d'accord avec l'idée ci-dessus par contre suis-je le seul à m'étonner de ne pas avoir un objet métier dépendant de la manière dont il persiste?

    Intuitivement j'aurais vu un "objet métier" et un "objet dédié à la persistance" de nos objets métier dans un support donné(bdd, ...)?

    Sinon je peux comprendre que mon exemple et un peu trop simple et il ne reflète aucunement un cas que je mets en pratique. Mais c'est vraiment impossible d'imaginer une application récupérant des données de sources différentes? Je sais pas moi la 1/2 des bons de commandes stockées directement en BDD grâce à une interface web et l'autre moitie provenant d'une application distante qui dépose des fichiers ds un format xml).
    Au final on veut bien mapper les 2 types sur un objet métier "Commande" pour faire nos traitements non?

    Désolé si ca semble bête mais je débute en architecture et j'essaye de bien comprendre pour les futurs cas pratiques
    D'avance merci

  4. #4
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    juin 2008
    Messages
    17 532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2008
    Messages : 17 532
    Points : 30 251
    Points
    30 251
    Par défaut
    Citation Envoyé par juju0169 Voir le message
    Je suis 100% d'accord avec l'idée ci-dessus par contre suis-je le seul à m'étonner de ne pas avoir un objet métier dépendant de la manière dont il persiste?

    Intuitivement j'aurais vu un "objet métier" et un "objet dédié à la persistance" de nos objets métier dans un support donné(bdd, ...)?
    Conceptuellement, l'object métier peut avoir des attributs "persistants".
    Lorsqu'on va réaliser cette propriété, il faudra bien la traduire d'une façon ou d'une autre i.e. faire le mapping entre les attributs concernés et la fonction de persistance d'une façon ou d'une autre.
    Comme en général, on utilisera un framework (spring, hibernate,...) il faudra bien traduire cela de la façon proposée par ce dernier.


    Mais c'est vraiment impossible d'imaginer une application récupérant des données de sources différentes?
    Nous pouvons tout imaginer... l'objet d'une architecture est de non seulement de proposer une solution mais faire en sorte qu'elle puisse être construite en tenant compte de contraintes physiques/techniques/budget/délais et des savoir faire existants.

    e sais pas moi la 1/2 des bons de commandes stockées directement en BDD grâce à une interface web et l'autre moitie provenant d'une application distante qui dépose des fichiers ds un format xml).
    Au final on veut bien mapper les 2 types sur un objet métier "Commande" pour faire nos traitements non?
    S'il s'agit de commandes, nous pouvons supposer que nos ensembles (xml et bdd) soient disjoints. Les traitements "communs" se baseront sur des attributs que les commandes devront avoir dans les deux ensembles.
    Comment relier commande utilisée par l'application métier et les commandes existantes dans les différentes BDD dépendra des traitements à effectuer...
    Exemples:
    S'il s'agit d'opérations de recherche/lecture style "état de traitement des commandes du client X", on pourra balayer les 2 BDD en espérant que le sens de "commande passée par le client X" puisse être traduite de façon consistante...
    S'il s'agit d'opérations qui changent l'état de... c'est plus compliqué.

    Le vrai soucis est qu'en général le SI est stratifié: commandes, clients,.... passées via le Web ne seront pas traitées par les mêmes processus et ces traitements ne s'appuieront pas sur les mêmes "informations".

    => les règles de changements d'état devront être cohérentes avec ces processus différents et... le rester dans le temps (i.e lorsqu'on fera évoluer les applications correspondantes).

    Si vous élargissez un peu le domaine, vous avez deux applications A et B qui font a peu près la même chose côté métier et l'envie de créer un C qui devra s'intégrer avec A et B.

    Si c'est du pilotage décisionnel, C pourra être un système BI et vous ramenez toutes les données dans un format +/- "commun" via des ETL qui pourraient stocker le tout dans un MDM. C'est très "buzz" et çà marche au moins sur le papier...

    Si c'est de l'opérationnel, on peut s'en sortir avec des réplications des commandes.
    Note: transférer les nouvelles commandes une fois par jour des A, B vers C ou en temps réel va être structurant côté techno retenue et impact sur l'existant.

    La difficulté n'est pas tant dans la réalisation technique d'un C qui tape dans les BDD de A et de B mais du maintien de la cohérence "dans le temps" vu que A, B et C ont généralement des fonctions (des owners) et des cycles de vie différents.

    Autrement dit, comment rendre "gérable" la dépendance de C par rapport aux informations produites par A et B - et éventuellement "transformées" par C - i.e. on a une boucle réactive.

    Pire A, B et C bougent... le compromis qu'on aura pu trouver ne durera que quelques mois....
    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  5. #5
    Futur Membre du Club
    Profil pro
    Inscrit en
    septembre 2010
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2010
    Messages : 7
    Points : 6
    Points
    6
    Par défaut
    Ok je vois le truc. Merci d'avoir pris le temps de me répondre.
    @++

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Persister mes objets métiers modifés
    Par n!co dans le forum Hibernate
    Réponses: 8
    Dernier message: 11/09/2006, 18h26
  2. Conseils sur la méthode de développement objet métier
    Par RamDevTeam dans le forum Langage
    Réponses: 5
    Dernier message: 08/12/2005, 18h14
  3. [DAO] Faire le lien entre les VO et les Objets Métiers
    Par mauvais_karma dans le forum Hibernate
    Réponses: 12
    Dernier message: 25/11/2005, 15h19
  4. [Strategie]Classes de mapping & Objets métier
    Par yanis97 dans le forum JDBC
    Réponses: 19
    Dernier message: 16/05/2005, 09h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo