Discussion :

[benwit]

Si le SQL est aussi normé sur les aspect procédures stockée (PSM : Persistant Stored Module). Notamment tout ce qui est gestion des variables, des exceptions, des curseurs....

Content de l'apprendre

(*) Néanmoins, beaucoup d'éditeurs se sont écartés de la norme (Oracle en particulier, SQL Server aussi).

on aurait du s'en douter

Mais c'est le seul moyen d'avoir des objets qui renvoient les mêmes données. Regardez le test que j'ai fait ici : http://sqlpro.developpez.com/cours/s...age=partie1#L3
Une même requête SQL toute simple donne différents résultats en fonction des différents SGBDR ! Mais ces résultats peuvent devenir identique en masquant les différentes écritures de cette même requête au sein d'une procédure. Et c'est le seul moyen d'être compatible entre différents SGBDR !

Bon d'accord et suite à ce que tu dis plus haut (*), tu n'utilises alors que ce qui est normé ?

L'ORM n'apporte pas actuellement cet avantage

Quand on me dit que c'est plus simple de changer de bases de données avec un ORM, je crois que c'est tout simplement un argument marketing à la c.

Le fond de ma pensée actuelle est plutôt : Un des objectifs de l'ORM devrait permettre d'apporter une réelle indépendance.
Je module mes propos parce que dans la pratique, ce n'est pas si transparent (requête jpa qui passe dans oracle mais pas dans mysql, attributs d'objet à renommer car "mots clés oracle", etc ...)

[Mektoub]

Un bien beau troll si l'en est

Le même qui revient tous les ans dans à peu près toutes les langues mais c'est divertissant, continuez ...

[dingoth]

TOTALEMENT faux ! Regardez les métriques de DULCIAN !
http://www.dulcian.com/Articles/Thic...ited_final.htm

Euh... Je suis très anti-ORM aussi et construis la plupart des requêtes complexes avec une bonne stored-procedure (mon bagage SQL et essentiellement PostGreSQL est important, même si ce n'est pas mon principal centre d'intérêt en programmation). Cependant, je dois admettre qu'en terme de développement pur, prendre hibernate, écrire son XML-qui-va-bien ainsi que les jointures directement en java est BIEN plus rapide et nécessite bien moins de tests que la stored-procedure et sa transformation en objet java utilisable (malgré DbUtils qui est un réel avantage lorsqu'on programme comme vous le préconisez).

Maintenant, on me dira "non" parce que ci ou ça, et parce que c'est écrit dans l'article cité.

Je persiste en expliquant ceci :
Avec Hibernate, une fois le mapping créé, nous travaillons directement avec les objets comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// Assomption : Hibernate est déjà configuré
try {
  return albums.getLabel().getArtistes().get(0).getNom();
} catch (HibernateException e) {
  ...
}

À l'inverse, une stored procedure:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 -- PgSQL
CREATE FUNCTION get_premier_artiste_du_label_du_cd AS
SELECT nom from artiste NATURAL JOIN album ON label_id LIMIT 1

et de son code java associé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
try {
  conn = ...;
  ps = conn.prepareStatement("execute get_premier_artiste_du_label_du_cd");
  rs = ps.executeQuery();
  return rs.getString(1);
} finally {
  DbUtils.closeQuietly(conn, ps, rs);
}

Lequel mettra davantage de temps à coder et sera plus difficile à tester ? Je crois pas qu'il y a vraiment photo. Et pourtant, je programme de la deuxième manière, qui est bien plus lente, mais qui fournit de meilleures performances.

Le second en outre est sujet à davantage d'erreurs, spécialement puisqu'il faut une communication certaine entre les deux développeurs qui peut parfois être conflictuelle, et j'ai quelques exemples de procédures mal documentées !

On me demandera certainement pourquoi mon choix sans ORM, tout simplement pour les performances et le trafic réseau, soit effectivement deux points soulevés dans l'article proposé par SQLPro. Mais je le sais pour avoir fait l'essai quelques fois : je mettrais moins de temps à développer avec Hibernate !

[pioug]

Voici un petit retour d'expérience sur utilisation d'ORM (hibernate, cayenne) sur plusieurs gros projets.


Les ORM sont des outils formidable mais très complexes a utiliser.

Avec hibernate vous pouvez vous passez du SQL en utilisant des requêtes objet (Criteria).

Concept très en vogue et très apprécié des nouveaux développeurs.

Gestion des transactions et des sessions simplifiée.

----------------------------------------------------------------------------------------------------------------

Si vous utiliser le générateur de mapping par défaut, vous êtes sur d'avoir des performances décevantes.

Le temps gagné en développement sera largement dépassé par l'optimisation et le re-modelisation du code. Ce type de Framework est souvent très mal utilisé par les développeurs.

Si vous développez sans activer les logs SQL vous n'optimiserez pas votre code correctement et donc aurez une application lente.

Ne pas utiliser de tels frameworks sur des opérations lourdes, se limiter à du CRUD.

Ces Frameworks sont pour la plupart associé à un cache qui n'est pas la solution miracle, c'est juste une rustine permettant de rééquilibrer la balance en comparaison à un développement classique.

----------------------------------------------------------------------------------------------------------------


Heureusement que la loi de moore existe, pour palier aux développements on SUR gonfle les serveurs. Les ORM ne font pas gagner du temps mais permettent de mieux structurer le code. Ils s'adressent en priorité aux développeurs expérimentés.

[Alesque]

Ce que font tous les SGBDR C/S et généralement en mieux...

Le session d'Hibernate c'est au niveau client, donc on s'évite le coût d'un voyage via le réseau pour bénéficier du cache. Ensuite on a le cache de niveau 2, toujours au niveau du client qui lui peut se synchroniser via le réseau si l'application est déployée sur plusieurs noeuds.

La notion de session (niveau 1) est très importante pour comprendre qu'elle peut nous éviter des voyages vers la base de données lors de l'exécution d'une UnitOfWork.

Sinon je te rejoins sur le point où l'ORM dans sa phase de déploiement doit aller beaucoup plus loin au niveau de son optimisation (création de triggers, de views, etc). Mais cela sera possible si un standard voit le jour à ce niveau là et que les vendors le suivent.

[BsT]

@dingoth

Le "getArtistes().get(0) " m'a tué... c'est malheuresement ce que semble reprocher SQLPro (avec un pseudo pareil ... ).

Il ne faut quand même pas pousser, il y a DB il faut s'en servir.

Pour moi les ORM sont des aides pour écrire du logiciel (CRUD généralement) : tu ne te paluches pas le code SQL.
Cependant mal utilisé on obtient des perfs horribles : dirty checking, flushing, mauvaises stratégies de chargement etc... (en SQL si tu oublies un index...)

Il ne sert à rien de parcourir toute l'arborescence d'objets pour récupérer une information, il convient de passer par une requête ou une procédure stockée.
(le meilleur des 2 mondes : en fait les ORM c'est le V et SQL le M dans MVC )

Dans le cadre d'une application métier je comprend l'utilisation d'un ORM, dans le cadre d'une alimentation d'un entrepôt de données je ne le comprendrais pas...

Enfin c'est perso mais SQLPro je te trouve un peu compact, les matheux comprendront ...

[Invité]

J'ai l'habitude de faire mes propres classe d'acces aux données et de ammping, avec l'habitude, on fait pour 3-4 classes et des relations en meme pas une demi journée et on est sur et certain de nos perfs.

J'ai essayé NHibernate (version .net de ... hibernate), et j'ai été franchement déçu : au début, c'est tout simple, plus apres on vois des requètes faites dans des boucles, donc tu passe la journée avec NHProf (payant) a trouver d'ou ça viens puis a bricoler un truc pour que ça passe.

Et franchement je suis 100 fois plus à l'aise en sachant quelle sont mes requètes exécutée, que etre novice sur une techno et risquer de perdre des données vitales.

[dingoth]

@BsT : Justement, c'est bien le point que je soulève. Un gars qui débute dans les ORM ferait certainement des bourdes aussi grosses que cela et qui bouffent des ressources inutilement. D'ailleurs, j'ai fait seulement une semaine d'Hibernate ; comme quoi... (et je suis vite reparti vers ma thick DB comme SQLPro le préconise).

Un gars qui débute en SQL fera très certainement moins de fautes de perfs (vraisemblablement il fera une requête du genre "SELECT * from artiste, album WHERE artiste.label_id = album.label_id LIMIT 1"). La bourde SQL devrait être équivalente à celle Java que tu soulèves.

Pour clarifier ma position, je suis partisan de la Thick DB, mais je n'accepte pas le critère de temps de développement moins élevé avec les DB, surtout venant d'un article non-daté faisant référence à des méthodes de programmation de 2000.

[BsT]

@dingoth :
Je connais des personnes expérimentées qui n'ont pas bien appréhendé
Hibernate.
C'est vrai que l'impression de facilité gâche l'expérience des ORM, certain ont oublié qu'il y avait une base de données derrière

Je trouve ta position beaucoup plus saine (plus ouverte) que celle de l'auteur du thread, et malheuresement c'est un prof...

@Alesque
Le cache de premier niveau permet bien évidement un gain de vitesse, mais il est surtout la pour assurer la cohérence de ton arborescence d'objets.

ex (2 chats avec le même propriétaire Petit):

cat1.getProprietaire().getNom() -> Petit
cat2.getProprietaire().getNom() -> Petit

cat1.getProprietaire().setNom("Dupont");
cat2.getProprietaire().getNom() -> Dupont

(dans la db il n'y a qu'un enregistrement propriétaire)

[notia]

Les ORM sont ils dangereux ? C'est une question que je me pose depuis 9 mois (le temps de faire un gosse, lol). Je travaille sur projet pour un grand compte, lorsque l'on regarde le temps que met un batch pour traiter toute la volumétrie, pres de 20H sur une machine AIX equipé de 12 processeurs à 4Ghz, 20Go de ram. Voir un traitement qui pendant 20H bouffe toutes les ressources (100%) de la machine, ca fait peur.
Ce que je trouve intéressant dans des framework tel que hibernate, c'est la partie gestion automatique du cache de données, plus besoin de mettre en place une solution sur le projet. Mais ces frameworks, nécessitent de tres grosses ressources pour de forte volumétrie, JVM 64bit de rigueur.

Par contre j'aimerais revenir sur les argument suivant:
- Maintenabilité: Des base de données, tels que oracle offre la posibilité de faire du dev genérique et objet, sur Oracle 10 et 11 on peut meme concevoir un modele de données objet. Il y a bien une raison au fait que ca coute la peau des fesses.
- Performance: Il est difficile de faire plus rapide qu'une requete directement sur le SGBD, notament grace à la possible utilisation de Hints, et de clause spécifique.
- Indépendance du SGBD: Si une boite investit dans un outils comme oracle, j'ose espéré qu'elle attende quelques années avant de changer de SGBD histoire d'avoir un retour sur investissement. Du coup l'indépendance du SGBD n'est intéressant que pour les éditeurs de progiciel, je pense que les client finaux et SSII n'y gagnent pas grand chose. De plus, la notion d'indépendance du SGBD empeche d'utiliser des parties optimiser d'un SGBD ou d'un autre

Je suis assez d'accord avec @SQLpro, sans aller jusqu'a dire que les ORM sont des immondisses. Les ORM apportent des idées que les SGBD auraient dû intégrer depuis belle lurette. Mais ce n'est peut-etre pas la direction à suivre, il faudrait peut-etre chercher à améliorer le concept des SGBD, tel que nous le connaissons aujourd hui.

[_skip]

De mon côté, nous utilisons joyeusement des outils comme cayenne (+ comme un mapper) et le gain de développement est réel.

Je pense que c'est presque un mythe de vouloir un monde full OO lorsqu'il y a une base de données relationnelle derrière, et c'est peut être là que certains débutants font des erreurs.

Celle que je vois souvent, c'est par exemple négliger les fonctions aggrégats.
Commencer à faire des sommes en bouclant sur une collections de "Orders" d'un objet "customer" en ne se rendant pas compte que cela nécessitera le chargement de certaines branches dans le graphe objet alors qu'on peut résoudre ceci efficacement en 1 aller-retour à l'aide d'une SUM en SQL et une ou deux jointures.
Un autre exemple qui revient souvent, c'est charger une collection d'objet à l'aide d'un select puis ensuite supprimer ses membres un à un au lieu de balancer tout de suite un DELETE en sql.

Pour éviter ça, je pense qu'il est simplement important de garder un oeil sur le code SQL envoyé par l'ORM à la base de données et ne pas attendre pour s'inquéter lorsqu'on constate que ça ne correspond pas du tout au SQL qu'on écrirait soi-même naturellement (multiples requêtes au lieu de jointures, etc...).

Pour ce qui est des procédures stockées, nous évitons car cela nous semble difficile d'implémenter du code métier en SQL plutôt qu'en java, et un mélange des deux risquerait de compliquer la maintenance.
Par contre y avoir exceptionnellement recours pour des traitements qui nécessiteraient beaucoup d'aller-retours, c'est tout à fait admis ici. Mais hors de question de faire des Insert et des Update d'une seule ligne avec des procédures stockées.

[Mektoub]

Pour éviter ça, je pense qu'il est simplement important de garder un oeil sur le code SQL envoyé par l'ORM à la base de données et ne pas attendre pour s'inquéter lorsqu'on constate que ça ne correspond pas du tout au SQL qu'on écrirait soi-même naturellement (multiples requêtes au lieu de jointures, etc...).

Pour ce qui est des procédures stockées, nous évitons car cela nous semble difficile d'implémenter du code métier en SQL plutôt qu'en java, et un mélange des deux risquerait de compliquer la maintenance.
Par contre y avoir exceptionnellement recours pour des traitements qui nécessiteraient beaucoup d'aller-retours, c'est tout à fait admis ici. Mais hors de question de faire des Insert et des Update d'une seule ligne avec des procédures stockées.

Bravo tout est dit : il faut réfléchir ... et analyser ce qui est naturellement produit par l'ORM pour adapter son utilisation !

[notia]

Bravo tout est dit : il faut réfléchir ... et analyser ce qui est naturellement produit par l'ORM pour adapter son utilisation !

Ca s'appelle de la bidouille, non?

[brice01]

Ne faudrait il pas que les éditeurs de SGBD respectent la norme SQL et l'enrichissent si nécessaire ?
Cela résoudrais le problème de portabilité !

[neo.51]

Dans ce cas là ne vaut-il pas mieux utiliser un générateur de code afin de modeler sa DAL aux besoins ?

Perso dés qu'une applis sort des classiques CRUD je préfère passer par un générateur de code pour modeler ma DAL en fonction de mes besoins parce que sinon utiliser un ORM et à coté coder une partie de l'accès aux données je trouve que ça manque de cohérence et que ça complique la maintenance du code...

[Alesque]

Dans ce cas là ne vaut-il pas mieux utiliser un générateur de code afin de modeler sa DAL aux besoins ?

Perso dés qu'une applis sort des classiques CRUD je préfère passer par un générateur de code pour modeler ma DAL en fonction de mes besoins parce que sinon utiliser un ORM et à coté coder une partie de l'accès aux données je trouve que ça manque de cohérence et que ça complique la maintenance du code...

Quels sont les outils que tu utilises pour générer tes DAL ?

[Maximil ian]

Les outils d'ORM ne sont évidemment pas des silver bullets. Personne n'a jamais prétendu qu'il fallait leur déléguer aveuglément 100 % des accès aux données.
Si 95 % des requêtes sont traitées automatiquement par l'ORM, c'est déjà très bien. Pour le reste (requêtes trop lentes ou trop complexes), il est évident qu'il faut passer par du SQL "à la main" ou une optimisation au cas par cas.

Je pense que gérer l'ensemble de la logique métier dans du code procédural au sein du SGBD serait revenir sur vingt ans de fruits du paradigme objet en matière de génie logiciel. Et aussi se priver de nombreuses pratiques de développement qui fonctionnent en synergie avec l'objet et dont l'efficacité est reconnue :

- design patterns
- refactoring
- test-driven development
- domain-driven design

j'en passe et des meilleures.

[dingoth]

Pour ce qui est des procédures stockées, nous évitons car cela nous semble difficile d'implémenter du code métier en SQL plutôt qu'en java, et un mélange des deux risquerait de compliquer la maintenance.

Pour maintenir à la fois des procédures stockées et du code java, je vois bien la difficulté que l'on pourrait ressentir. Cependant, elle n'est pas présente. Il suffit de savoir séparer d'une part les données et d'autre part le reste (et pas spécialement la couche de présentation : la coordination entre les systèmes par exemple). La maintenance est relativement aisée, malgré les centaines de procédures stockées et les milliers de classes que nous avons. Si les architectes de l'application font bien leur boulot, pas de souci, tout sera là ou ça doit être et en fonction de la nature du problème, l'endroit d'où il provient sera évident.

[Jester]

Si les architectes de l'application font bien leur boulot, pas de souci, tout sera là ou ça doit être et en fonction de la nature du problème, l'endroit d'où il provient sera évident.

Un code métier n'utilisant que les données d'une BD devra être dans le SGBD (pour éviter les accès multiples), mais si à un moment il a besoin d'une ressource (webservice par exemple) qui n'est pas dans la BD il sera réintégré dans le code classique (hors BD). Donc du coup c'est plus floue de savoir où doit être quoi car ça dépend de si ça utilise une ressource tierce ou pas, pas forcément évident à savoir.

Pour moi, les serveurs d'applications devraient aussi servir de SGBD (ou l'inverse), ainsi tout serait regroupé.

[dingoth]

Nous avons différentes databases. Pour effectuer une requête d'un de nos clients, nous devons impérativement piocher dans plusieurs de ces bases de données. En outre, nous avons parfois besoin d'un accès à un webservice.

Pour cela, nous distinguons la transaction relationnelle (de base de données) de la transaction applicative. Généralement et selon le système dans lequel je développe, une transaction applicative regroupe plusieurs transactions relationnelles. Et lorsque nous faisons appel à des web-services, ce n'est qu'une étape de la transaction applicative, complètement indépendante d'une transaction relationnelle. Oui, dans le cadre de l'application que je décris, Java n'a comme rôle que de gérer les transactions applicatives, de faire des appels à des systèmes tiers (y compris bases de données et web-services) et de formatter la réponse pour le système appelant.

Nous nous basons énormément sur des diagrammes. Le premier et le plus important est celui de l'intéraction entre les systèmes : cette application se connecte à tel système et tel système. C'est tout. D'autres diagrammes sont des sortes de zoom et disent dans quel contexte un processus se connecte à tel ou tel système. (Une transaction applicative est une exécution d'un processus, pour que vous compreniez mon vocabulaire ; on pourrait dire processus = classe et transaction = instance.)

Ceci est parfaitement résumé dans mon message précédent : « si les architectes de l'application font bien leur boulot, pas de souci. »