Comment organiser et gérer les informations d'identification de bases de données multiples dans l'application?

Question

D'accord, je suis la conception d'un service Web autonome (en utilisant Restlet comme mon cadre). Mon application est divisée en 3 couches:

• couche de données (juste au-dessus de la base de données, fournit des API pour se connecter à / interrogation, et un objet de base de données)
• couche objet (responsable de sérialisation de la couche de données ... fournit des objets dont la couche client peut utiliser sans se soucier de la base de données)
• couche client (Cette couche est le service Web Restlet ... fondamentalement juste crée des objets de la couche d'objet et de la demande satisfait webservice)

Maintenant, pour chaque objet que je crée dans la couche d'objet, je veux utiliser différentes informations d'identification (donc je peux sandbox chaque objet ...). La couche d'objet ne devrait pas connaître les informations d'identification exactes (IE le login / pw / DB URL etc).

Quelle serait la meilleure façon de gérer cela? Je pense que je devrais avoir un super classe d'objets de base de données dans ma couche de données ... et chaque sous-classe contiendra les informations de connexion nécessaires ... Ainsi ma couche d'objet peut juste aller Database db = new SubDatabase(); puis continuer à utiliser cette base de données.

Au niveau du client, ils seraient simplement être en mesure d'aller ItemCollection items = new ItemCollection(); et ont aucune idée / contrôle sur la base de données connectée obtient.

Je demande cela parce que je suis en train de faire mon extensible plate-forme, de sorte que d'autres peuvent facilement créer des services hors de ma plate-forme.

Si quelqu'un a une expérience avec ces problèmes d'architecture ou la façon de gérer ce genre de chose que je vous en serais reconnaissant une idée ou des conseils ...

Ne hésitez pas à poser des questions si cela est source de confusion. Merci!

Ma plate-forme est de Java, le cadre REST J'utilise est Restlet, ma base de données est MySQL.

Answer 1

Je sens ce que vous nous avez expliqué est sensible et que vous essayez de ne pas exposer les détails de base de données et les informations d'identification au niveau de cleint.

Pour cette situation, vous devez penser à des modèles de conception qui pourraient vous aider Je peux penser à un singleton, où vous créez une instance et l'utiliser dans la couche d'objets, évitant ainsi montrer des détails sur les URL credentails et aux utilisateurs.

Deuxième option, ce que je reçois dans mon esprit est l'utilisation de la couche de mise en veille prolongée, qui vous aidera à cacher les détails et que les objets ORM et vous pouvez obtenir ce que vous recherchez.

Answer 2

Ma suggestion est d'utiliser JTA où vous pouvez utiliser plus d'une base de données avec un nombre respectif de sources de données. vous pouvez consulter ici pour plus d'infos https: //test.kuali .org / confluence / affichage / KULRICE / source de données et + + + JTA Configuration

Answer 3

Je l'écho des commentaires de @ Saugata. Regardez printemps et injecter votre implémentation de source de données (ou les talons pour le test!) À votre couche objet dans votre ressort configuration. Cela devrait aider votre architecture globale de l'application dans un certain nombre de façons:

1. Vous serez en mesure de changer les bases de données (soit des instances ou des implémentations) à la volée sans recompilation de code.
2. Vous aurez résumé la source de données complètement à partir de son application -. Vous permettant d'échanger une base de données pour un service Web, la mise en œuvre de file d'attente, ou un talon
3. Découplage votre application de cette manière, il sera plus facile à tester.