Comment concevoir OTI lorsque la source de données varie dynamiquement

Question

En général, lors de la définition d'un OAC, vous auriez un setter pour la source de données sur l'objet DAO. Mon problème est que notre source de données varie dynamiquement en fonction de la demande au serveur. à savoir chaque demande peut accéder à différentes instance de base de données.

La demande contient des propriétés logiques, qui peuvent ensuite être utilisés pour récupérer la connexion à la DB de la demande.

Alors, quand la dépendance injection du DAO à l'objet logique métier, je besoin d'un moyen de définir les propriétés du DAO à l'exécution (configuration non temps).

Une solution consiste à stocker la source de données sur le fil local, mais je ne aime pas vraiment jouer avec fil variables locales.

Une autre option est d'avoir une méthode d'initialisation sur l'objet logique métier qui appelle l'initialisation sur le DAO avec les propriétés de la requête.

Je suppose que c'est un problème commun, pouvez-vous proposer une solution commune?

Answer 1

Il semble que votre problème est que vous créez une instance unique de DAO pour votre application. Soit vous devez créer une instance distincte pour chaque source de données (peut-être faire une sorte de contrôleur dao pour gérer tout cela pour vous) ou peut-être permettre à vos méthodes dans votre dao pour être statiques et de transmettre toutes les informations sur la façon de se connecter à la source de données ainsi que les données que vous persistez dans toutes les méthodes.

Answer 2

Votre problème est un peu déroutant. Avoir un accès DAO plusieurs sources de données différentes semble être un cauchemar d'entretien. Par conséquent, vous devez définir une interface DAO contenant toutes les méthodes que vous voulez appeler. Pour chaque base de données que vous connectez à je construire une nouvelle classe qui implémente l'interface DAO. Cela vous permet d'avoir plusieurs implémentations. Je puis stocker ces mises en œuvre (chacun qui a sa propre source de données) dans une carte (java.util.Map), en utilisant vos « propriétés logiques » comme la clé de la carte. Étant donné que tous vos OAC mettre en œuvre votre interface Implémentations vous serez en mesure de les jeter à l'interface et les utiliser de manière interchangeable. Sur votre objet métier, vous injecter la carte de mises en œuvre DAO. J'espère que cela aide votre conception.

Answer 3

Vous pouvez regarder dans cette classe:

http: //static.springframework.org/spring/docs/2.5.x/api/org/springframework/jdbc/datasource/lookup/AbstractRoutingDataSource.html

Ce sera plus facile pour vos objets de service et des objets d'accès aux données à ignorer que toute notion de dynamique existe datasources.

En général, vous aurez besoin de mettre en œuvre un filtre de servlet et d'utiliser un ThreadLocal afin que la mise en œuvre DataSourceLookup utilisé par AbstractRoutingDataSource peut facilement accéder aux paramètres de la requête qui déterminent ce qui DataSource est retourné. Si vous voulez vraiment éviter cela, vous pouvez mettre en place un filtre de servlet qui définit les propriétés sur un haricot scope demande et injecter le grain de café dans la mise en œuvre DataSourceLookup que vous avez écrit. scope demande en grains utilisent encore un ThreadLocal dans leur mise en œuvre, mais au moins cette façon, il est le impl de printemps, pas le vôtre, et vous n'avez pas besoin de vous en inquiéter. :)

Une approche similaire est décrite dans cette entrée de blog de l'équipe de printemps:

http://blog.springsource.com/2007/01 / 23 / dynamique source de données de routage /

Answer 4

J'ai eu un tel problème sur un projet client / serveur. projets client et serveur partageais interfaces Dao. Et je devais choisir la mise en œuvre de Dao approprié Quand je l'habitude de faire l'opération de base de données. Ma solution était comme ceci:

IVehicleDao vehicleDao =daoFactory.Get<IVehicleDao>(parameters);
vehicleDao.doSomething();

Obtenir dao de l'usine en passant parameters.Inside usine Dao qui décide la mise en œuvre Dao pour revenir ..

Answer 5

Je l'ai déjà fait cela. Vous devez créer une classe OAC chaque, et dans le cadre de votre DAO vous devez passer la source de données et enfin une classe CONTRÔLEUR où vous faites appel dynamique DAO.