2009-09-28 7 views
0

J'ai une application qui exécute plusieurs requêtes (query1, query2, query3) par rapport à une base de données, récupère des données et publie ensuite ces données.Conception appropriée

La façon dont je suis allé sur la conception de c'était:

a. Avoir une classe DB qui encapsule la connexion, l'exécution de la requête, la transformation du jeu de résultats en POJO.

b. Une classe éditeur qui sait comment publier le pojo.

c. Un contrôleur qui, au début, exécute a puis envoie la sortie à b.

public void start(){ 
    List<DataPojo> pojoList = db.executeAndRetrieveResult(); 
    for (DataPojo p : pojoList){ 
     publisher.publish(p); 
    } 
} 

d. Un gestionnaire qui contient une liste de contrôleurs. Lorsqu'il est invoqué, itère et demande au contrôleur de démarrer.

public void start(){ 
    for (Controller c : controllerList){ 
     c.start(); 
    } 
} 

La vie de l'application était simple et donc bonne.

Mais maintenant je dois faire une modification qui implique, en prenant des données de query1, en combinant avec les données de query2, puis en les publiant.

Auparavant, les contrôleurs étaient homogènes. La différence entre eux a été encapsulée dans la requête qu'ils ont exécutée (en utilisant la classe Db).

Cependant, maintenant j'ai besoin de savoir quel contrôleur exécute quelle requête donc je sais où obtenir la sortie de query1 et query2.

Est-ce qu'un motif de conception que je peux utiliser pour faire interagir le contrôleur1 et le contrôleur2 tout en les gardant relativement lâchement couplés?

Vive

Répondre

2

La commune chose que les gens font ici est de séparer l'application en couches. La couche "inférieure" (ou la couche la plus proche de la base de données) interagit simplement avec la base de données et traite des entités DB simples. Si cela n'est pas suffisant, il y a généralement une "couche de gestion" dans laquelle vous pouvez mettre une logique pour combiner des entités db, encapsuler des objets construits à partir de combinaisons d'entités atomiques db, etcetc.

La partie frontale, quelle qu'elle soit, interagit avec la couche de gestion. Le point principal est d'éviter de mélanger la logique métier (comment les entités db vont se combiner) avec la logique db (obtenir et définir des valeurs pour des entités db individuelles).

En tant que motif, vous trouverez des discussions à ce sujet sous des titres tels que "3-tier" ou "N-tier".

1

Je créerais une interface wrapper pour vos requêtes, quelque chose comme QueryExecutor, qui a alors deux implémentations. Un simple QueryExecutory qui exécute juste une requête comme vous avez maintenant, et un MultiQueryExecutory ou LinkedQueryExeutor (ou une telle, vous avez l'idée) qui prend dans les deux requêtes qui sont liées. Demandez à votre classe MultiQueryExecutor d'exécuter les deux requêtes, puis de faire votre logique de traitement de post-requête avant de renvoyer les données publiées combinées.Cela vous permet également d'effectuer ultérieurement toutes sortes d'opérations d'interrogation souples, comme un StopOnFirstResultsMultiQueryExecutor dans lequel vous pouvez charger une liste de requêtes, mais il arrête et publie les résultats du premier qui trouve> 0 résultat . Ce n'est qu'un exemple, mais j'espère que le message sera clair.

Questions connexes