Version imprimable
Bonjour,
J'envisage d'intégrer le design pattern décorateur sur mes objets métier.
Et comme j'utilise Hibernate je me demande si les deux vont bien ensemble.
Je ne trouve pas de retour d'expérience, .
J'aimerai savoir si ça dégrade les performances d'accès aux données.
Si c'est dur à implémenter et à maintenir
J'ai peur que le résultat soit un peu lourd à relire
Cordialement
Fabrice
1) on ne met pas des décorateur pour le plaisir d'en mettre, mais on en met our un besoin bien précis, donc pas besoin de tout décorer. Si t'as besoin de tout décorer pour 1 besoin, alors t'as un problème de design, c'est peut être pas le décorateur dont t'as besoin.
2) je ne vois aps trop le rapport avec Hibernate. Hibernate te retourne tes entités base de données. La logique business n'y a trop pas sa place, c'est le boulot de tes controllers et éventuellement de tes DAO.
J'ai créé mes objets en retenant le minimum commun à mes différents utilisateursCitation:
Envoyé par tchize_
J'ai des propriétés, qui ne sont pas partagées par tous les utilisateurs.
Si il y en avait qu'une je pourrais faire un héritage.
Mais dans mon cas il y en a plusieurs
Si je me cale sur ma première classe, il y a deux propriétés optionnelles
Un utilisateur voudra aucun ajout.
Un autre utilisateur voudra une des deux propriétés, et un autre utilisateur voudra l'autre.
Tandis qu'un utilisateur peut vouloir les deux.
Donc je pense, que je suis dans le contexte du design pattern décorateur.
Je veux enrichir mes objets sans passer par l'héritage
Car je ne peux pas faire une classe fille par configuration
Il va bien falloir que je rajoute ses propriétés dans mes classes, @Entity.Citation:
Envoyé par tchize_
Je ne sais pas trop comment faire passer la pilule à Hibernate
Au niveau des DAO je pense faire comme avec l'héritage, je récupère des objets ou un objet sans me soucier du type exact de ce que je récupère.
Et si il le faut je cast après
Pour être honnête, je connais le DP décorateur plus en théorie qu'en pratique.
Pour l'implémentation dans le code, ça va me demander de la relecture de cours
J'ai surtout peur que dans la bdd ça se traduise par des jointures des requêtes lourdes, car hibernate empreinte parfois des chemins bizarre.
Surtout si je mélange les objets avec des décors différents
Je comprend pas, tu parle de quoi quand tu parle d'utilisateur? Tu parle de client (genre une app livrée presque similaire à plein de clients) ou des gens connectés. Normalement tes entités sont les mêmes pour tout tes users. Tes entités mappent des tables, et au dernières nouvelles, les tables SQL c'est pas dynamique. Donc tout doit s'y trouver. Après si tu veux pas présenter l'un ou l'autre truc à la vue, c'est le boulot de la vue, pas des entités. La pattern décorateur elle sert à ajouter des comportements (ou en changer) quand on retourne un Object X à un appelant, en permettant d'appliquer ça quelle que soit la sous classe impliquée (typiquement quant t'as pas le contrôle sur la classe). Après tu peux décorer tes objets avant de les retourner à la vue si ça te chante, mais hibernate n'en aura pas la moindre connaissance. Sans compter que décorer un graphe, c'est vachement plus costaud que décorer un objet.
On rigole pas SVP. :P
comme j'ai une formation en comptabilité et en informatique, j'ai un projet personnel de logiciel de comptabilité, les scénarii retenu sont les suivants une tpe, et des pme avec un petit service comptable.
Je m'en sers surtout pour tester des technologies Java et faire de la veille technologique, sur un sujet métier que je connais bien.
J'en ai parlé à des amis comptables, qui ont exprimé des avis/besoin très différents.
Pour le métier j'ai retenu un noyau commun à tout le monde, un minimum légal du métier, tout le monde est d'accord dessus.
Au moment de créer une nouvelle comptabilité, on crée une base de données avec son graphe propre, qui tiens compte des choix de l'utilisateur.
Une société une base, pas question de mélanger les comptabilités
Par exemple pour enregistrer les écriture comptables certains voudrait avoir un champs "date de pièce", "numéro de pièce", et d'autres aurait besoin de tenir leur comptabilité en multidevises.
D'autres voudrait quand même faire pouvoir faire de la comptabilité analytique, je vais donc avoir des informations supplémentaires à stocker sur certains des mouvements comptables
Il faut donc adapter le schéma aux choix de l'utilisateur à la création d'une nouvelle comptabilité.
Ce sont les variantes que j'ai décidé de retenir, pour débuter.
Concernant les champs "date de pièce" et "numéro de pièce", c'est surtout pour les recherches.
Ca permet de retrouver une écriture d'après le numéro de la facture.
Ca ne concerne pas un certains nombre d'écriture qui ne reposent pas sur un document par exemple opérations diverses,écritures d'inventaire,...
J'ai aussi pensé faire un champs informations ou je stockerai tout en JSON ou XML, plutôt JSON sur un modèle de base de données documents, pour faire les recherches.
Mais le pattern Décorateur est peut être une solution, au moins pour certaines propriétés.
Si je veux étendre les comportements je passe par une interface et Hibernate s'en moque.
Mais la j'ai bien des décors en plus, bien distincts.
Bon Cheese je te trouve un peu rigide. :D
Mon modèle n'a pas de problème.
J'ai trouvé le minimum légal commun à tout les scenaris.
Mon idée était de laisser la possibilité aux utilisateurs de l'étendre selon leur besoin, car je ne peux pas gérer toutes les combinaisons possibles.
Pour moi c'est l'idée du décorateur.
Mais le dp décorateur est un peu lourd à mettre en place avec Hibernate, d'après mes lectures sur le web.
Donc je prèfère l'écarter, au moins pour l'instant.
Je vais faire de l'héritage si il n'y a qu'un décor .
Et pour la suite je vais creuser la piste NoSql modèle document colonne
Mais se sera sûrement mongo db donc document, car il est intégré par Hibernate.
Ce sera mieux que de bricoler une colonne avec du JSON
Merci
désolé du retard de réponse :)
Pour ce genre de situation (modèle commun, plus propriétés spécifiques à chaque installation), ce n'est pas trop le décorateur l'idéal, car il implique du code, de la complexité et des dévelopement spécifiques à chaque fois, ce qui n'accélère pas les déploiement. Et ça ne résoud pas le problème de l'affichage.
En général, j'ai vu des applications qui passaient par un mix de deux solutions
un core avec tout ce qui est commun, additionné de ce qui le plus courant, avec des options pour cacher ce qui n'est pas nécessaire dans l'interfaces. Au niveau JPA ca se résumùe à des modèle, au niveau interface, ca se résume à des 'if has feature X, show bouton X'
Des possibilité d'ajouter des propriété custom dans différents object via un Map<Key,Value>, pour ce qui est d'ajouter les propriétés custom à chaque client qui n'ont aucun intérêt à être générique, voir qui n'ont même pas possibilité d^'etre prévu.
Niveau donnée au final ca ressemble à ça pour faire simple
Et un affichage qui seraitCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Code:
2
3
4
Au final j'ai le sentiment que le dp décorateur et hibernate ça tend vers l'usine à gaz.
Dans mon cas chacuns a sa base de données, mais ça ne règle pas le problème
L'idée était de mettre ce dont chacun à réellement besoin
Comme j'ai beaucoup de propriétés optionnelles basiques, je pense que je me dirigerais vers hibernate et mongodb
L'idéal serait de mélanger relationnel pour la partie commune et mettre le reste dans un champs type document en JSON
Et un peu d'héritage
Merci
Il y aurait éventuellement l'héritage par discriminant pour faire ce que tu décris... le discriminant serait dans ton cas une colonne qui identifie ton client (ou ton implémentation).
Tu aurais une table représentant le socle commun et autant de tables liées pour les colonnes spécifiques.
L'avantage que j'y vois est que tu continues à faire des requêtes sur ta table de base mais Hibernate te renverra des instances d'objets "spécialisés" (commun + spécifique).
Bref, regarde ceci, ça te donnera une idée de ce qui est possible de faire.
Personnellement, j'utilise cette technique dans le cadre de spécialisation de documents.
J'ai une partie commune et des propriétés complémentaires dépendantes du type de document.