Tout d'abord, pour JDBC, une grande simplification du processus peut être opéré conjointement par la génération automatique de code et l'utilisation de Spring JDBC Template pour les cas "non standards". La génération de code est une solution souvent, et à tord, écartée qui peut permettre d'extraire d'un schéma de base la DAO "basique" qu'Hibernate fabrique dynamiquement. Fonctionellement cela abouti au même résultat. Ensuite pour l'épineux problème des selects, Spring JDBCTemplate permet de garder un bon rapport performance/maintenabilité.
De manière générale, la facilité de maintenance d'un système de développement est souvent liée à la capacité de ceux qui en ont la charge à mettre en place des solutions efficace de rationalisation. A titre d'exemple, certains projets où j'ai eu à jouer les pompiers, avec leurs 200 fichiers .hbm, étaient bien loin d'être d'être optimum A se stade, il aurait mieux fallu écrire les requêtes à la main.
Ceci dit, chaque approche apporte son lot d'avantages et d'inconvénients. J'ai aussi un longue expérience professionnelle qui me fait dire qu'en ce domaine il n'est jamais de règle absolue. Si j'ai à construire l'architecture d'un système de gestion dont le système d'information est remplis au grès d'étapes de saisie humaines (typique d'une application de gestion), la perte de performance induit par hibernate va clairement être compensé par la maintenabilité. En revanche lorsqu'il s'agit par exemple de stocker en base des données remontant en flux (données financières, issues de systèmes embarqués, etc), hibernate devient un problème et le gain de maintenabilité est complètement éclipsé par des performances désastreuses. De même s'il s'agit d'une application amené à faire des requêtes en simple lecture sur une base massive.
Tout cela pour dire que même si je suis un peu ironique dans mon introduction, ce benchmark n'a pour autre but que de faire prendre conscience que le choix hibernate a un coût et que ce coût ne peut être négligé qu'à partir du moment où l'on a clairement évalué et même testé cette solution sur les véritables volumétries que l'application aura à prendre en charge.
Donc pour reprendre (sans ironie) ta phrase
Bref, sur des projets dont le développement est coûteux et destinés à durer, ils faut mieux choisir Hibernate dès le début pour gagner du temps par la suite.
, je reformulerais en disant que pour choisir, il faut déjà être sur de l'endroit où l'on met les pieds, et ensuite seulement, Hibernate est un choix qui présente des avantages, tout comme JDBC.
En somme, tout choix d'architecture est raisonnable, s'il est raisonné, et basé sur les véritables informations, pas les mythes de performance relayés par plus les enthousiastes et/ou les plus intéressés Car si ce n'est pas une surprise pour toi, un tel décalage de performance en a été une pour moi, surtout après avoir été de nombreuse fois "contré" sur certains choix d'architecture par un "Hibernate est aussi rapide, si ce n'est plus rapide, que du natif". Un rapport de 3 à 7 selon l'opération, sur un million d'enregistrement, c'est loin d'être une paille...
Dernier point avant d'arrêter mes jacasseries, le fait de tout penser objet comme tu l'évoques est aussi un facteur de perte de performances. Car le monde objet et le monde relationnels sont suffisamment éloignés pour que le fait d'éloigner cette contrainte des tâches quotidiennes d'un développeur, lui fasse produire des architecture intrinsèquement sous-optimales par rapport à ce que peu produire une base de donnée "moderne".
@Gronono
Tout d'abord, pour JDBC, une grande simplification du processus peut être opéré conjointement par la génération automatique de code et l'utilisation de Spring JDBC Template pour les cas "non standards". La génération de code est une solution souvent, et à tord, écartée qui peut permettre d'extraire d'un schéma de base la DAO "basique" qu'Hibernate fabrique dynamiquement. Fonctionellement cela abouti au même résultat. Ensuite pour l'épineux problème des selects, Spring JDBCTemplate permet de garder un bon rapport performance/maintenabilité.
De manière générale, la facilité de maintenance d'un système de développement est souvent liée à la capacité de ceux qui en ont la charge à mettre en place des solutions efficace de rationalisation. A titre d'exemple, certains projets où j'ai eu à jouer les pompiers, avec leurs 200 fichiers .hbm, étaient bien loin d'être d'être optimum
A se stade, il aurait mieux fallu écrire les requêtes à la main.
Ceci dit, chaque approche apporte son lot d'avantages et d'inconvénients. J'ai aussi un longue expérience professionnelle qui me fait dire qu'en ce domaine il n'est jamais de règle absolue. Si j'ai à construire l'architecture d'un système de gestion dont le système d'information est remplis au grès d'étapes de saisie humaines (typique d'une application de gestion), la perte de performance induit par hibernate va clairement être compensé par la maintenabilité. En revanche lorsqu'il s'agit par exemple de stocker en base des données remontant en flux (données financières, issues de systèmes embarqués, etc), hibernate devient un problème et le gain de maintenabilité est complètement éclipsé par des performances désastreuses. De même s'il s'agit d'une application amené à faire des requêtes en simple lecture sur une base massive.
Tout cela pour dire que même si je suis un peu ironique dans mon introduction, ce benchmark n'a pour autre but que de faire prendre conscience que le choix hibernate a un coût et que ce coût ne peut être négligé qu'à partir du moment où l'on a clairement évalué et même testé cette solution sur les véritables volumétries que l'application aura à prendre en charge.
Donc pour reprendre (sans ironie) ta phrase
, je reformulerais en disant que pour choisir, il faut déjà être sur de l'endroit où l'on met les pieds, et ensuite seulement, Hibernate est un choix qui présente des avantages, tout comme JDBC.En somme, tout choix d'architecture est raisonnable, s'il est raisonné, et basé sur les véritables informations, pas les mythes de performance relayés par plus les enthousiastes et/ou les plus intéressés
Car si ce n'est pas une surprise pour toi, un tel décalage de performance en a été une pour moi, surtout après avoir été de nombreuse fois "contré" sur certains choix d'architecture par un "Hibernate est aussi rapide, si ce n'est plus rapide, que du natif". Un rapport de 3 à 7 selon l'opération, sur un million d'enregistrement, c'est loin d'être une paille...
Dernier point avant d'arrêter mes jacasseries, le fait de tout penser objet comme tu l'évoques est aussi un facteur de perte de performances. Car le monde objet et le monde relationnels sont suffisamment éloignés pour que le fait d'éloigner cette contrainte des tâches quotidiennes d'un développeur, lui fasse produire des architecture intrinsèquement sous-optimales par rapport à ce que peu produire une base de donnée "moderne".