[Découpage en couche] besoin d'arguments

Salut,

Alors voilà, je bosse sur une application en java avec un modèle bien défini et une architecture 3 tiers tout ce qu'il y a de plus classique, avec des javabean pour le model, des DAO pour l'appels aux bases de données qui retournent des objets, des class controller, des handler... bref une belle application bien structuré...

Normalement, quand on veut traîter des données issue de la base de données en suivant des règles définies dans le modèle, on a un handler, qui appelle un DAO, puis le DAO query la base de données, crée une instance d'un javabean, le set grâce au record en cours, éventuellement l'ajoute à une collection d'objet du même type, puis retourne au handler la collection qui peut alors lui appliquer d'autres règles en appellant éventuellement d'autres handler ou simplement en le retournant au controller.

Mon boss lui, il veut que j'applique record après record, donc, entre chaque rs.next() avec rs étant une instance de ResultSet, les règles business et qu'en fin de programme je rs.close().
En plus, il crois dur comme fer que le ResultSet est un flux permanent entre la base de données et java qu'il est donc judicieux de ne pas charger en mémoire tout son contenu mais n'utiliser que record par record pour des raisons de performance.

En gros, il mélange le DAO, le controller et le handler et j'ai beau lui dire "Non ce n'est pas comme-çà qu'on fait du java ou n'importe quel langage orienté objet" il me demande pourquoi et je ne vois pas comment lui prouver qu'il a tord.

Si vous avez des arguments, je suis preneur :cry:

[ Modéré par Viena ]
Ajout d'un tag et modification du titre : Pour la compréhension de tous, utilisez un titre clair et les tags ! merci.
:arrow: Les Règles du Forum

Sors lui la javadoc...

Citation:

---

"A table of data representing a database result set, which is usually generated by executing a statement that queries the database. "

---

ça veut bien dire ce que ça vaut dire. Tout est dans le resultSet.

Ou encore mieux, va en mode debug à l'endroit ou tu récupère le resultset et montre lui que y a tout dedans ;)

En général pose toi la question à toi-meme .

1) Pk traiter toute la logique métier dans la boucle (while(rs.next())
est une moins bonne idée que de passer par des DAO , .....
2) Quelle est l'avantage de complexifier enormément le programme
par des notions d'architeture ( des Design-Pattern ) .

Répondre à ces questions revient à expliquer ce qu'est la programmation
orientée objet !!

Bon alors je viens de le voir il m'a expliquer ce qu'il veut faire en détail.
Côté mélange des business c'est un peu mieux.

Selon lui, lorsqu'on obtient un ResultSet, une partie des record sont en mémoire dans le ResultSet, une parti se trouve en cache géré par le driver JDBC et une partie, si le cache n'est pas assez gros, est locked dans la base de données.

Ok, c'est fort possible pour des milliers de records.
Il veut tester côté performance un truc du style :

Le DAO serait un singleton sur lequel un statement et un resultset serait ouvert sur une query.
Le DAO possèderait une méthode du style getNextObject qui retournerait null s'il n'y a plus rien dans le ResultSet.
Cette méthode ferait un rs.next() et fabriquerais l'instance de l'objet sur base du record et le retournerait.

Il y aurait une methode createResultSet(String query), une methode closeResultset().

Vous voyez l'ambiance?

Mon handler créerais une boucle du style :

Code:

---

1 2 3 4 5

MonObjet obj = dao.getNextObject(); while obj != null { // applique le modèle sur obj obj = dao.getNextObject(); }

---

Ce qui veut dire que le ResultSet serait ouvert en permanence, y compris le statement et la connection, mais à la limite c'est pas grave pour ces 2 derniers car ils ne lock pas de table ni de record.

Mon Boss souhaite ainsi contrôler la charge en mémoire de l'application en jouant sur le nombre de record dans le ResultSet au même moment.

Sun proposes l'utilisation de l'interface RowSet qui permet donc de créer ce genre de flux tendu entre la base de données et le DAO, et mon boss est donc joyeux tout plein.

Alors, bien ou pas bien?