Archive

Articles taggués ‘base de données’

iBATIS : l’autre framework de persistance

Introduction

De quoi faire frémir un Angry Bird

Si je vous dis “framework de persistance”, vous allez immédiatement penser Hibernate ou TopLink, car ce sont je pense deux des ORM les plus répandus dans notre cher monde J2EE. Cependant il en existe un autre, moins connu, qui propose des fonctionnalités parfois intéressantes : iBATIS. Par chance, j’ai travaillé sur un projet qui utilise ce framework, je vais donc vous le présenter dans cet article.
Lire la suite…

Share

Pourquoi pas des requêtes spécifiques ?

Aujourd’hui je vais vous présenter un petit truc tout bête pour améliorer les performances d’une application utilisant un ORM, et en particulier de l’affichage d’une page de type back-office.

Problème

Vous avez un problème de performance lors de l’affichage d’une page importante de votre application. La page en question ne contient en gros qu’un tableau de données, avec une vingtaine de colonnes, le tout paginé qui plus est. Un cas assez courant dans les applications de gestion type back-office.

Votre chef vous explique que les utilisateurs seraient plus heureux (plus productifs en tout cas) si la page s’affichait instantanément plutôt qu’en 5 ou 10 secondes. Votre AMOA vous regarde avec pitié et étonnement : elle affiche le même tableau sans soucis dans son Squirrel avec une requête SQL pas très compliquée. Le directeur de projet vous soutient qu’Hibernate/JPA c’est lent et qu’on était mieux en JDBC.

Pour afficher le tableau en question, vous passez par une requête JPA/QL qui sélectionne les entités que vous cherchez (disons Person), puis vous utilisez le graphe d’objets résultant pour afficher la page :


1
String hql = "select p from Person join fetch ... where p.age > 18 ...";

Bien sûr Person est une classe énorme avec toutes les informations imaginables (pays de naissance, nom de l’école maternelle, nom de jeune fille de la grand mère paternelle, …), et vous avez  besoin de fetcher des associations en plus pour charger vos informations. L’ORM traduit tout cela en une ou plusieurs requêtes peu efficaces (sous selects, jointures, …) et chargeant beaucoup de données (50 colonnes sur trois tables), dont finalement peu sont utilisées. Lire la suite…

Share