Je suis confronté à un problème plutot simple mais je n’ai pas trouvé de solution qui me paraissait plus intéressante que les autres, alors j’aimerais avoir votre point de vue.
J’ai un serveur central qui offre une interface EJB et qui abrite une base de données couplée a un ORM/JPA. Mon modèle est plutot satisfaisant, et il existe évidemment pas mal de clés étrangères entre les entités.
Maintenant, ce serveur central doit partager le modèle avec des serveurs intermédiaires, plus légers (probablement des conteneurs légers genre Jetty/Tomcat).
Il est important que les tomcats puissent bénéficier du modèle complet sans avoir a envoyer une requete au serveur central a chaque fois qu’ils ont besoin de lire un objet.
Plusieurs solutions s’offrent:
Soit le modèle est refilé a l’aide de DTO a travers l’interface EJB. Je trouve ca un peu lourd, et surtout contraignant pour la transmission des relations ManyToMany (il faut du coup prévoir une requete SQL particulière qui renvoie toutes les associations… et cela pour chaque relation MtM.)
Soit on part sur une solution de réplication de BDD, ou chaque serveur intermédiaire serait assisté par une copie en lecture seule de la BDD centrale. Néanmoins, cela pose pas mal de soucis car la copie ne pourra pas etre complete (les serveurs intermédiaires ne partagent pas les memes lignes dans chaque table.), et cela rend assez complexe la mise en place de la réplication…
Soit une autre solution que je n’ai pas envisagé.
Que feriez vous a ma place? Ou quelles sont les questions que j’ai pu oublier de me poser ?
Non mais ton DTO est pas oblige d’etre un mapping 1:1 de ton modele. En general la vue “objet” que peut avoir un client est bien plus plate que ce que t’es oblige de faire pour avoir un modele coherent au niveau JPA/base de donnee. En general tu mets tes DTO derriere une API qui est orientee au niveau de sa logique vers une vision “business” des choses et pas modele.
Donc en gros:
BDD <-> JPA/ORM <-> Cache <-> Facades + business logic <-> DTO/API <-> Cache<-> Clients type Tomcat pour UI ou autre.
Au passage si t’utilise un truc type active record pour tes entites JPA, faut faire super gaffe a pas utiliser les methodes de persistences en dessus de la couche facade, sinon c’est supra crade.
De l’exterieur tu vois jamais que API+DTO et ils sont versiones independament de tout ce qui est dessous. Ca peut monter en charge assez loin a moins que t’ai un probleme assez specifique dont t’as pas parle ou que t’ai besoin de 99.9999% de dispo. Deja a la base si t’as une BDR faut etre pret a avoir a mini deux heures par an de down time…
Avoir une copie de la BDD en local en lecture seule ca m’a fait vomir dans la bouche un peu pour etre honnete…
Marrant, on a la même problématique ici dans ma mission. Je bosse sur une appli centrale interrogée en Corba par une “interface” qui sert aussi de cache et qui réplique plus ou moins le même modèle avec une DTO. Il n’y a pas trente-six alternatives malheureusement, même si un travail préalable de raffinement du modèle peut grandement faciliter le boulot.
En particulier la sécabilité du modèle en sous-modèles avec des liaisons un peu plus faibles que des clefs étrangères (codes & transco entre sous-modèles). Si ton modèle devient assez volumineux pour être aidé par un cache comme tu le décris, il est aussi probablement assez gros pour être scindé en plusieurs morceaux. Là tu peux choisir d’avoir une DTO sur les sous-modèles qui en ont vraiment besoin, et c’est une économie de dév/maintenance.