Discussion :

[juju0169]

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.

[wiztricks]

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

[juju0169]

Pour commencer merci pour cette première réponse.

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

[wiztricks]

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

[juju0169]

Ok je vois le truc. Merci d'avoir pris le temps de me répondre.
@++