Discussion :

[lespoches]

Il sert un peux à rien ce thread car tout le monde sait que tout est une question de cout & moyen || contrainte.

J'ai collaboré sur des projets H24 7/7 avec 10min de coupure max par an et on a utilisé Hibernate. On a gagné du temps sur nos DAO et on a pu à coté réfléchir sur le clustering, le load-balancing...

Actuellement sur un projet sans moyen, beh je met en place une archi orienté ejb3/JPA. On me donnerait plus de moyen et les contraintes seraient plus fortes, bah je ferais pas forcément différemment.

Je peux vous dire que l'ORM couplé à l'OXM, et bien je gagne pas mal de temps et de plus, c'est totalement flexible. Mon appli sera customizable depuis mes xsd (dans la limite du raisonnable).

[B.AF]

Il sert un peux à rien ce thread car tout le monde sait que tout est une question de cout & moyen || contrainte.

J'ai collaboré sur des projets H24 7/7 avec 10min de coupure max par an et on a utilisé Hibernate. On a gagné du temps sur nos DAO et on a pu à coté réfléchir sur le clustering, le load-balancing...

Actuellement sur un projet sans moyen, beh je met en place une archi orienté ejb3/JPA. On me donnerait plus de moyen et les contraintes seraient plus fortes, bah je ferais pas forcément différemment.

Je peux vous dire que l'ORM couplé à l'OXM, et bien je gagne pas mal de temps et de plus, c'est totalement flexible. Mon appli sera customizable depuis mes xsd (dans la limite du raisonnable).

H24 7/7 ça n'a jamais signifié 100 ms de latence max, ni des algorithmes complexes en grid ,etc,etc....
Dans le genre hors sujet péremptoire :

[lespoches]

Je me suis mal exprimé mais dans le fond je me comprends.
Quand tu recoie un message d'alerte et que le but de ton soft c'est d'alerter les secours afin de sauver des personnes en détresse !!! Et pourtant oui, ya de l'H...

http://fr.wikipedia.org/wiki/Cospas-Sarsat

[lespoches]

Dans le genre hors sujet péremptoire :

... Wow mais tu es d'une humeur ! Faut changer de métier mon gars !

[souviron34]

J'ai collaboré sur des projets H24 7/7 avec 10min de coupure max par an et on a utilisé Hibernate.

H24 7/7 chez moi ça fait 0 minutes de coupure....

Et j'ai travaillé sur des softs comme ça..

Mais sans Hibernate re


Nan, sérieux, ça fait pas sérieux...

Ou alors c'est que c'est pas H24 7/7...

[lespoches]

H24 7/7 chez moi ça fait 0 minutes de coupure....

C'est tout à fait vrai et c'est bien pour ca que des personnes sont payé pour faire des etudes de risques (inondation, chimique, viral...)

Mais malgrès toute ces études et tout ce que tu peux mettre en oeuvre pour parer à la moindre éventualité, eh bien il arrive que ca merde d'où le pouillem accordé car c'est pas de l'embarqué.


Tout ca pour dire que les ORM sont très largement répandu et qu'ils conviennent à la majorité des projets (même ceux à risque). D'autre part, je ne pense pas que l'API de persistance Java est vu le jour comme ca juste pour le fun. Il s'agit d'une capitalisation de best-practice sur un nombre majoritaire de projet orienté nouvelle techno.

[B.AF]

Tout ca pour dire que les ORM sont très largement répandu et qu'ils conviennent à la majorité des projets (même ceux à risque). D'autre part, je ne pense pas que l'API de persistance Java est vu le jour comme ca juste pour le fun. Il s'agit d'une capitalisation de best-practice sur un nombre majoritaire de projet orienté nouvelle techno.

Oui enfin nouvelle techno, hibernate, ca reste du java et une librairie, rien de plus. C'est plus un concept qu'une techno.

Après une autre réalité, c'est que ce n'est pas parce que la majorité utilise une techno que cela en fait la meilleure. C'est la plus répandue. Point.

Les ORM ne conviennent pas à la majorité des projets : embarqué ? client mobile ? pas de db ? traitements de fichier ? Calculs scientifiques ?

L'ORM c'est surtout un choix. Souvent mal fait parce que facilité, et après mal utilisé parce qu'on se dit "bon ben je vais générer du code maintenant". C'est surtout ça la réalité de l'ORM.

Et en plus, ils ne fonctionnent pas tous de la même façon, n'ont pas tous les mêmes patterns et les même contraintes.

C'est comme SQL Server et ORACLE : connaitre le SQL n'a jamais garanti qu'on puisse se servir parfaitement des deux.

C'est comme hibernate : connaitre le java n'a jamais garanti qu'on s'en serve correctement. Je serai curieux, parce que je n'en ai jamais rencontré en fait, de connaitre la statistique exacte du nombre de personnes qui ont déjà forké, modifié ou simplement regardé à l'intérieur du moteur pour comprendre.

Je dirai 5%. Pas plus. Comme les utilisateurs de JBoss d'ailleurs.

[_skip]

Si tu regardes du coté cayenne, je suis à l'origine de quelques modifications du code de la version 3.0. Mais c'est un mapper pour moi, pas un ORM et je m'en sers surtout pour éviter de faire directement du SQL dans mon code client.

J'ai adopté ce mapper pour quelques projets légers parce qu'il est pas trop invasif et parce que sa communauté était très sympa et que les gens de la mailing list répondaient gentiment à mes questions sans essayer de me faire passer pour un idiot.

[maxxyme]

Si tu regardes du coté cayenne, [...]

J'ai adopté ce mapper pour quelques projets légers parce qu'il est pas trop invasif et parce que sa communauté était très sympa et que les gens de la mailing list répondaient gentiment à mes questions sans essayer de me faire passer pour un idiot.

Ce qui voudrait dire que ce n'est pas le cas du côté d'Hibernate...

[B.AF]

Bof, en même temps 90% des questions sur le groupe nh mériterait un RTFM sans sommation.
Je crois que le plus drôle c'est que "comment gérer une session" doit être demandé 52 fois par jour en moyenne.

[OButterlin]

Ah oui, c'est un peu d'humour dans ce monde de brute, mais c'est la fatigue tous les jours de supporter ceux qui veulent faire de la techno pour faire de la techno, du process pour faire du process, du sgbd pour faire du sgbd...

Ca bouffe une énergie...

Pas mal, mais réversible...

Ça bouffe une énergie folle de supporter ceux qui veulent en rester à l'assembleur, utiliser les api les plus bas niveau pour accéder aux données de la base, etc...

La vérité est sûrement entre les 2

[ego]

Toutes ces histoire de framework et d'ORM sont les plus belles merdes mercatiques que l'on a fait depuis l'existence de l'informatique. Si vous voulez avoir l'assurance de ne pas finir à temps votre prijet et que ce dernier soit inexploitable lors de la montée en charge, alors allez-y, amusez vous bien avec Hibernate et les frameworks associé comme JPA...

Voici un extrait de l'article que je suis en train d'écrire sur les dérives de ce genre d'immondices...

6 – Pourquoi pas un ORM ?

Bonne idée, mais mauvaise pioche… Les outils actuels de mapping relationnel objet, d’Hibernate à iBatis en passant par l’inabouti Entity Framework, possèdent tous les mêmes défauts. Malgré tous les caches qu’on leur met les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client . Pire encore lorsque l’on compare ce que fait l’ORM par rapport à une procédure stockée. En sus les transactions durent plus longtemps car il faut se payer les temps de communications réseau entre les serveurs, ce qui augmente la durée des verrous sur les tables et diminue donc la capacité globale du système à absorber la charge, alors que c’est un des principaux argument de vente (cherchez l’erreur !). Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données et qu’il faut à la fois l’un et l’autre si l’on veut être rigoureux. Quant au pilotage du niveau d’isolation des transactions de données, comme les développeurs ne savent même pas de quoi il s’agit, on en constate généralement l’absence !
Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les développeurs cela leurs permet de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leurs carences.
Quant à l’argument qui consiste à dire que la maintenabilité d’un code client est bien plus simple qu’un code relationnel, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire. De plus la maintenance d’un service se fait à froid, alors que dans la base c’est nativement à chaud. Bref l’argument de facilité de maintenance largement répandu, montre encore une fois l’étendu du désastre culturel : pour avoir, par manque de formation, laissé les développeurs dans l’ignorance des possibilités de codage dans un SGBDR, pour avoir parfois choisit les mauvais outils (MySQL, SQLite…) on a contourné le problème en y ajoutant des couches superflues, alambiquées et coûteuses, tant en licence, qu’en temps de développement ou en administration.

Toon Koopelars nous donne ce graphique si pertinent (figure 2). On y voit les possibilités des SGBDR croîtrent de façon exponentielle, tandis que leur utilisation commence à décroître brusquement avec la mode d’utilisation de certains outils comme les ORM ou l’arrivée de SGBD pseudo relationnels…

A lire sur le sujet :
http://www.dulcian.com/Articles/Thic...ited_final.htm
http://thehelsinkideclaration.blogsp...vc-part-2.html

A +

Moi ça me fait penser aux débats Assembleur->C puis C->C++ puis C++->Java.
Regardez aussi Windows XP ou Vista par rapport à Windows 3.1 (oui je parle aux vieux là ). Quand j'ai commencé l'informatique on faisait tout avec le code sur une disquette et seule la partie devant s'exécuter était chargée dans mon monstre de 512Ko !!
Qu'est-ce que cela peut bien faire d'écrire une requête en base avec SQL ou avec HQL ? Vous croyez que parce que vous avez écrit vous même la requête "à la main" elle est meilleure ? C'est TOTALEMENT faux. Il s'agit simplement d'une facilité d'écriture, seulement.
La très grande majorité des requêtes SQL sont de simples requêtes avec 1 ou 2 jointures et c'est tout à fait normal avec l'approche objet. Car dans le monde objet, on charge un objet et on navigue de proche en proche dans les relations entre objets. Donc de simples requêtes du genre "donne moi les dossiers suivis par ce collaborateur". Alors à quoi cela sert d'écrire "à la main" ?
Par contre, si on a des requêtes plus complexes dans des cas limites parce que l'on a une vraie requête "transverse" aux objets de toute manière, l'ORM ne va pas nous aider car il est là pour faire du chargement "simple" en général. Dans ces cas, où même une requête HQL pourra être faite, on peut tout à fait déclarer la requête directement en SQL "natif".

Donc où est le problème, vraiment je ne vois ABSOLUMENT pas ?!

[OButterlin]

Moi ça me fait penser aux débats Assembleur->C puis C->C++ puis C++->Java.
Regardez aussi Windows XP ou Vista par rapport à Windows 3.1 (oui je parle aux vieux là ). Quand j'ai commencé l'informatique on faisait tout avec le code sur une disquette et seule la partie devant s'exécuter était chargée dans mon monstre de 512Ko !!
Qu'est-ce que cela peut bien faire d'écrire une requête en base avec SQL ou avec HQL ? Vous croyez que parce que vous avez écrit vous même la requête "à la main" elle est meilleure ? C'est TOTALEMENT faux. Il s'agit simplement d'une facilité d'écriture, seulement.
La très grande majorité des requêtes SQL sont de simples requêtes avec 1 ou 2 jointures et c'est tout à fait normal avec l'approche objet. Car dans le monde objet, on charge un objet et on navigue de proche en proche dans les relations entre objets. Donc de simples requêtes du genre "donne moi les dossiers suivis par ce collaborateur". Alors à quoi cela sert d'écrire "à la main" ?
Par contre, si on a des requêtes plus complexes dans des cas limites parce que l'on a une vraie requête "transverse" aux objets de toute manière, l'ORM ne va pas nous aider car il est là pour faire du chargement "simple" en général. Dans ces cas, où même une requête HQL pourra être faite, on peut tout à fait déclarer la requête directement en SQL "natif".

Donc où est le problème, vraiment je ne vois ABSOLUMENT pas ?!

Allo, ici un vieux...
Alors, oui, avec Windows 3.1 on faisait tourner de gros programmes de 512ko (énorme !) et maintenant il ferait 5Mo...
Quelque part, on s'en fout un peu... non ? Il est généralement admis que windows bouffe beaucoup (trop) de ressources, Linux pour la même chose serait largement plus light en mémoire...
Enfin, je comprends ton point de vue... Les anciens ne veulent plus trop s'adapter et se tourne vers le passé en disant "ah, c'était mieux avant"...
Ceci dit, rien que pour établir une connexion avec un serveur avec SNA, on passait quelques heures... quand ça fonctionnait... Mais une fois que ça fonctionnait, c'était du feu de dieu ! (le débat du bon et du mauvais chasseur )
Il faut vivre avec son temps...

[Luc Orient]

... Ceci dit, rien que pour établir une connexion avec un serveur avec SNA, on passait quelques heures... quand ça fonctionnait... Mais une fois que ça fonctionnait, c'était du feu de dieu ! (le débat du bon et du mauvais chasseur )
Il faut vivre avec son temps...

Puisqu'on parle de ce bon vieux Mainframe et que c'est mon domaine professionnel, je vais ajouter une modeste contibution au présent débat en citant un "gourou" en matière de SGBD sur le Mainframe (DB2 z/OS), à savoir Susan Lawson, qui sait de quoi elle parle :

Canonical Database Architecture and DB2 Performance ... Really ?

Sans recouper totalement l'article de SQLpro, on peut noter quand même quelques points de convergence.

Quelques morceaux choisis :

As with any database design, the best performance is achieved using direct access via SQL to the database objects. Getting only the data that’s needed when it’s needed is the key to achieving high performance. Introducing layered access to your data stores can negatively impact database performance. A generic data access object lends itself to generic database performance. The performance issues created by generic data access can’t be resolved by tuning the database or system resources, such as adding memory or CPU. This is solely a problem of the application.
...
The key to high-performance database design is to move data-intensive processes as close to the data as possible. This allows for filtering of data to occur close to the data, and less data to be passed around and processed by other data processing layers.
...
You should seriously consider the costs associated with generic design and denormalization. Consistent use of denormalization as a solution to data access costs for a generic design can slow or even halt a company’s update operations. One company that experienced this problem eventually had to abandon their entire development effort and restart with a more specifically tuned design. This occurred after investing years of development time and money. Even if they could have achieved acceptable performance, their other goal of having a flexible, accessible database (via SQL and Web applications) could never have been realized.

... etc ... etc ...

Il va sans dire que je partage totalement ce point de vue ...

[OButterlin]

Puisqu'on parle de ce bon vieux Mainframe et que c'est mon domaine professionnel, je vais ajouter une modeste contibution au présent débat en citant un "gourou" en matière de SGBD sur le Mainframe (DB2 z/OS), à savoir Susan Lawson, qui sait de quoi elle parle :

Canonical Database Architecture and DB2 Performance ... Really ?

Sans recouper totalement l'article de SQLpro, on peut noter quand même quelques points de convergence.

Quelques morceaux choisis :



Il va sans dire que je partage totalement ce point de vue ...

Il se pourrait que ton point de vue soit quelque peu faussé.
Si tu travailles sur mainframe, ce n'est certainement pas sur des applications pour 100 utilisateurs. Du coup, le côté performance a un poids peut-être un peu supérieur.
Il est certains aussi qu'avec une application plus proche du temps réel, on ne va pas s'amuser à traverser n couches...
Ne crois-tu pas en fin de compte qu'il est plus juste (et sage) de dire que finalement, tout dépend de ce qu'on développe.

[Luc Orient]

Il se pourrait que ton point de vue soit quelque peu faussé.
Si tu travailles sur mainframe, ce n'est certainement pas sur des applications pour 100 utilisateurs. Du coup, le côté performance a un poids peut-être un peu supérieur.
Il est certains aussi qu'avec une application plus proche du temps réel, on ne va pas s'amuser à traverser n couches...

Certes ... ce n'est pas faux ...

Ne crois-tu pas en fin de compte qu'il est plus juste (et sage) de dire que finalement, tout dépend de ce qu'on développe.

Voilà une réflexion qui me semble frappée au sceau du bon sens et que je ne peux qu'approuver ... C'est d'ailleurs en partie ce qu'écrit Susan Lawson dans la conclusion de l'article que j'ai cité.

[OButterlin]

Voilà une réflexion qui me semble frappée au sceau du bon sens et que je ne peux qu'approuver ... C'est d'ailleurs en partie ce qu'écrit Susan Lawson dans la conclusion de l'article que j'ai cité.

Damned, on va m'accuser de plagiat (désolé, je n'avais pas lu)

[ego]

Allo, ici un vieux...
Alors, oui, avec Windows 3.1 on faisait tourner de gros programmes de 512ko (énorme !) et maintenant il ferait 5Mo...
Quelque part, on s'en fout un peu... non ? Il est généralement admis que windows bouffe beaucoup (trop) de ressources, Linux pour la même chose serait largement plus light en mémoire...
Enfin, je comprends ton point de vue... Les anciens ne veulent plus trop s'adapter et se tourne vers le passé en disant "ah, c'était mieux avant"...
Ceci dit, rien que pour établir une connexion avec un serveur avec SNA, on passait quelques heures... quand ça fonctionnait... Mais une fois que ça fonctionnait, c'était du feu de dieu ! (le débat du bon et du mauvais chasseur )
Il faut vivre avec son temps...

Au risque de ne pas t'avoir compris, je crois que c'est toi qui n'a pas compris ma remarque. Je ne suis justement pas attaché au passé et je pense que ceux qui sont contre les ORM sont parfois des gens attachés au passé, justement.

Donc vive l'avenir !!

[Invité]

Au risque de ne pas t'avoir compris, je crois que c'est toi qui n'a pas compris ma remarque. Je ne suis justement pas attaché au passé et je pense que ceux qui sont contre les ORM sont parfois des gens attachés au passé, justement.

Ce n'est pas parce que c'est une évolution qu'elle est bonne.
Ces arguments me font penser au gens qui soutiennent les technique du "Make an web 2.0 app only with drag'n drop" ...

Les ORM ont le gros défaut d'être une couche technologique a connaitre en plus pour le développeur : un développeur qui utilise un ORM sans connaitre SQL va droit dans le mur. Donc au final le dev doit connaitre le langage + SQL + l'ORM. Une bonne évolution n'est pas censé enlever des connaissances nécessaires ?

Mais vous inquiétez pas les MVP et autre expert vont bientôt trouver une techno pour "faciliter" la passerelle entre l'orm et le langage ... mince ça existe deja (activerecord par exemple)... on appelle ça comment ? Un Object to Object - Relationnal Mapping ? A quand un OOOOROOOOM ?

Je ne dit pas par la que ce sont des mauvais produits : leurs utilisation dans l'industrie est très répandu donc je n'aurais pas la prétention de dire que tout le monde se plante.

Mon post a l'air d'un troll, mais je pense qu'il faut se souvenir de ma première phrase.

[fr1man]

Les ORM ont le gros défaut d'être une couche technologique a connaitre en plus pour le développeur : un développeur qui utilise un ORM sans connaitre SQL va droit dans le mur. Donc au final le dev doit connaitre le langage + SQL + l'ORM. Une bonne évolution n'est pas censé enlever des connaissances nécessaires ?

Déjà, SQL doit faire partie (je l'espère) du savoir de base d'un développeur.
Donc c'est un faux problème.
Pour ce qui est de la couche à connaitre en plus, c'est alors valable pour tous les autres frameworks autre que ORM. On est quand même censé ne pas réinventer la roue à chaque fois, et donc si on utilise d'autres briques logicielles, la moindre des choses c'est d'apprendre à bien s'en servir, ou alors il faut changer de boulot.
Encore un faux problème à mon sens.