2 votes

Méthodes Dao, manipulation d'objets simples/multiples et fermeture de ressources

Le conseil habituel est de fermer les ressources JDBC lorsqu'elles ne sont plus nécessaires. Cela peut être fait dans un catch et un finally. Toutefois, que se passe-t-il si une méthode DAO ne manipule qu'un seul objet de domaine et qu'une opération nécessite la récupération/création de plusieurs de ces objets en une seule fois ? Le fait d'obtenir une déclaration puis de la fermer à plusieurs reprises poserait-il un problème en termes de performances ? Si tel est le cas, faut-il créer une méthode distincte pour gérer plusieurs objets en une seule fois ou faut-il retarder la fermeture d'une manière ou d'une autre ?

1voto

Kent Points 71470

Je pense qu'il n'y aurait aucune différence si l'application est basée sur Dao ou non. Ces ressources devraient être fermées. Si vous travaillez sans framework (spring, hibernate etc)

java.sql.Connection doit être remis dans le pool, s'il y avait un pool. Les objets ResultSet et Statement doivent être fermés après l'exécution de la requête.

Selon votre architecture, ces codes de gestion des ressources pourraient être placés dans des classes Dao ou d'autres classes. Par exemple, il existe des classes qui se concentrent sur la création et l'exécution de requêtes SQL. Les codes de gestion des ressources pourraient se trouver dans ces classes.

Si vous travaillez avec certains frameworks, ces derniers se chargent généralement de la gestion des ressources pour vous.

1voto

BalusC Points 498232

Vous pourriez ajouter une couche de transaction supplémentaire au dessus de la couche DAO et appeler setAutoCommit(false) sur le Connection au début de la transaction/session, laissez les méthodes DAO utiliser la même méthode que celle utilisée pour la transaction/session. Connection et ensuite commit() le site Connection lorsque la transaction/session est terminée/fermée. Vous devrez cependant modifier les méthodes DAO pour qu'elles prennent un fichier Connection comme argument supplémentaire, ou pour le stocker ThreadLocal (ce qui doit cependant être fait avec beaucoup de précaution car les threads peuvent être mis en commun).

La création de déclarations ne devrait pas être si onéreuse, tant que vous utilisez régulièrement PreparedStatement qui sont généralement compilés et mis en cache dans la base de données.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X