Discussion :

[B.AF]

Mais SQLPro il dit quoi lui ?

Ben je crois qu'il suffit de relire

Mais c'est certain que j'aimerai aussi comprendre comment ilfait en tout sql pour réduire les accès en base sur les données, gérer le multi site, multiples fuseaux horaires, et pleins de choses, mais bon.
Moi je crois qu'on est dans un cas d'hyper spécialisation avec ses avantages (je lui ferai confiance les yeux fermés sur l'audit d'une base) et ses inconvénients (incapacité à juger une technologie en sortant de la spécialisation).

Son fond de commerce c'est le sql, donc forcémment, il ne prône pas l'ORM, ce qui est dommage car (et j'espére qu'il le lira ça!) il a la connaissance SQL et SGBD nécessaire à aider l'implémentation de ces outils. C'est parce que le monde de l'ORM compte trop de développeurs objets qu'il y a tant de dysfonctionnement.

Moi je serai prêt à consacrer du temps à faire un tuto sur la génération de code et l'intégrité dans un ORM. Ce serait bien non ?

[Fabske]

Je découvre ce sujet, et me suis dit que c'est assez marrant car c'est le même genre de débat qui se passe un peu partout depuis ... 4 ans. Oui à l'époque c'était pas trop les ORM, mais plutôt Store Proc vs Query dynamique. D'ailleurs le 1er post (de SqlPro) fait un peu un amalgame entre ORM et Query dynamic.

Il y a 4 ans pour développer une nouvelle application j'ai du faire le choix entre un ORM ou travailler par Store Proc. J'ai choisi l'ORM, pour le nommer c'est LLBLGEN. Après 4 ans, je peux en faire un bilan. Evidemment je n'ai pas utilisé d'autres ORM depuis, mais ça peut donner une idée.

Performances:
Les performances par rapport à une Store Proc "crud" sont bien plus basse. Mais si on veut faire une SP qui sélectionne les données sur plusieurs critères qui peuvent être null, on en arrive à créer la query dans la SP et là les perf sont semblables. Ou alors ont doit faire 1 SP par combinaison de critères null/non-null et là on se retrouve vite avec des milliers de SP. Bref au niveau performance, pour moi c'est ok tant que ce n'est pas un point critique. Dans mon projet, quelques fonctionnalités très intensives sur les données ont été faites sous SP, et donc l'ORM gère 95% des queries.
De la même manière, il faut surveiller les queries générées par l'ORM pour détecter les problèmes de performance, et réécrire ces queries (en utilisant l'ORM differemment ou en utilisant une SP) si nécessaire.
Le plus gros désavantage a été l'utilisation plus élevée de la mémoire. Quand on travaille sur des milliers d'objets en même temps, ça commence à devenir limite. Donc à ne pas utiliser si c'est un point critique ou en tenir compte dans le design de ce genre de process (ce qu'on a fait).

Réseau:
Le paragraphe sur le temps réseau qui augmente le lock est vrai, mais ce n'est pas spécifique à un ORM. Si on prend cet argument en compte alors il ne faut plus jamais écrire de query dynamique et uniquement fonctionner avec des store proc.

Temps de développement plus court: vrai ... et faux dans certains cas.
Vrai, SI on connait l'ORM assez bien (ou si le projet est long, comme dans mon cas sur plusieurs années). Apprendre à utiliser un ORM pour un projet de 3-6 mois, c'est une perte de temps. Mais si on le connait bien, ça fait gagner un temps énorme.

Indépendance vis-à-vis de la db: vrai ... et faux, à nouveau.
On peut jamais être complètement indépendant (il y aura toujours des SP & View à maintenir pour chaque type de DB). Mais si dès le design on pense aux spécificités de chaque type de DB sous lequel ça va tourner (type de champs, longueur des noms, héritage etc.) on peut en effet arriver, avec un ORM, à avoir le même code qui tourne sous plusieurs SGBDR. Mais ça veut dire
1) Il faut quand même réécrire et maintenir les SP & views,
2) Il ne faut utiliser aucune fonctionalité propre à un SGBDR (c'est si vite fait...). Ca implique une bonne connaissances des SGBD

La phrase pour la maintenance d'un service à froid (dans le 1er post du thread), j'ai rien pigé, désolé .

En résumé:
On peut faire ce qu'on veut, rajouter une couche ne peut qu'alourdir / ralentir le traitement (c'est la même chose avec LINQ p.ex.). Maisç a a tjrs été comme ça. Le .NET lui^même est un exemple (les applications real-time sont toujours faite en c++).
Mais par contre ça a beaucoup d'autres avantages. En tout cas moi j'ai été convaincu de l'utilité des ORM. En plus, les serveurs sont toujours plus puissant et ont tjs plus de mémoire, alors si on peut se le permettre autant utiliser ça (sinon, on coderait toujours en assembleur).
Bref, les ORM c'est comme toutes les autres technologies: il faut voir en fonction du projet si c'est utile.

[ego]

Une réponse pleine d'intelligence
Merci à toi

[captainKirk]

Une petite touche de philosophie :
ORM vs Stored Proc, Blanc vs Noir, Yin vs Yang, on n'en revient toujours au même, tout est une question d'équilibre. L'un n'empêche pas l'autre, l'un n'existerait pas sans l'autre. C'est l'association des deux qui crée la beauté du monde.

[wiztricks]

Une petite touche de philosophie :
ORM vs Stored Proc, Blanc vs Noir, Yin vs Yang, on n'en revient toujours au même, tout est une question d'équilibre. L'un n'empêche pas l'autre, l'un n'existerait pas sans l'autre. C'est l'association des deux qui crée la beauté du monde.

Je suis d'accord avec la métaphore mais, dans ce débat, nous sommes il y a tension entre (au moins) deux aspects complètement différents:

• Des traitements plus près des données que permettent les Stored Procedures ont des atouts côté performances indiscutable (lié à la vitesse finie de la lumière)
• Un ORM permet de faire vite et pas cher (en se passant de DBA), c'est indéniable.

Problèmes:

1. Faire des choses compliquées sans DBA,
2. Compliquer les choses et exploser les coûts,
3. Faire vite une application promise à croître. A terme elle deviendra instable et remettre d'équerre un machin tordu sans valeur ajoutée fonctionnelle sera un exercice incertain et risqué: tant qu'on pourra ajouter du hard, des caches,... çà pourra le faire... jusqu'au moment ou on se résignera à tout jeter à la poubelle.

Solution à vite, pas cher, évolutif???
En ce moment, j'explore les possibilités d'ORM de type Active Records Pattern.

J'ai toujours un ORM mais les instances sont des lignes de tables: on limite un peu l'expressivité côté ORM. Mais la base de données ne se limite pas à un concept de persistance...
Elle reste fortement matérialisée et cela permet d'y enfouir des SP dans un deuxième temps.
- W

[B.AF]

Je suis d'accord avec la métaphore mais, dans ce débat, nous sommes il y a tension entre (au moins) deux aspects complètement différents:

• Des traitements plus près des données que permettent les Stored Procedures ont des atouts côté performances indiscutable (lié à la vitesse finie de la lumière)
• Un ORM permet de faire vite et pas cher (en se passant de DBA), c'est indéniable.

Problèmes:

1. Faire des choses compliquées sans DBA,
2. Compliquer les choses et exploser les coûts,
3. Faire vite une application promise à croître. A terme elle deviendra instable et remettre d'équerre un machin tordu sans valeur ajoutée fonctionnelle sera un exercice incertain et risqué: tant qu'on pourra ajouter du hard, des caches,... çà pourra le faire... jusqu'au moment ou on se résignera à tout jeter à la poubelle.

Solution à vite, pas cher, évolutif???
En ce moment, j'explore les possibilités d'ORM de type Active Records Pattern.

J'ai toujours un ORM mais les instances sont des lignes de tables: on limite un peu l'expressivité côté ORM. Mais la base de données ne se limite pas à un concept de persistance...
Elle reste fortement matérialisée et cela permet d'y enfouir des SP dans un deuxième temps.
- W

En gros, ca reveint à dire que l'on est obligé de faire du propriétaire ou de faire n'importe quoi c'est un peu réducteur.

L'ORM est l'active record n'ont rien à voir. L'ORM est le principe d'avoir un design drivé par les objets, ce qui fait son abus d'usage aujourd'hui le plus courant :
1 -Code généré incontrôlé
2 -Problèmes de stratégies de chargements de données
3 - Forte dépendance à la modélisation SQL

A l'inverse, générer la base depuis le modéle objet permet un bien plus grand contrôle sur les règle d'intégrités, les contraintes, les checks et autres objets.

Reste une étape de fine tunning qui sera une politique d'indexation sur certains objets clefs.

En outre, l'ORM apporte une deuxième technologie qui est la gestion d'un cache de données (statique ou distribué) qui permet d'alléger le volume de réquêtes émises.

Utiliser un ORM n'a jamais signifié se passer de procédures stockées, de vues, de contraintes d'intégrité.

L'Active Record est une logique là de mapping, mais les problèmes sont les mêmes, il n'offre pas de meilleure approche que l'ORM.

Pire, l'active record étant l'inverse (une utilisation relationnelle d'objets) il est potentiellement encore plus dangereux pour les performances sur le sujet.

La bonne solution reste :
- Bon outil pour bonne tâche
- Maitriser la génération de code
- De ne pas croire que l'utilisation de l'un ou l'autre supprime le besoin de compêtences fortes
- Ne pas utiliser d'ORM quand on n'a pas d'expérience (ni faire d'article au passage)

[ego]

* Des traitements plus près des données que permettent les Stored Procedures ont des atouts côté performances indiscutable (lié à la vitesse finie de la lumière)
* Un ORM permet de faire vite et pas cher (en se passant de DBA), c'est indéniable.

Je ne suis pas d'accord avec ce résumé.
1- Les stored proc sont plus rapides quand on peut coder la logique dedans. Si la logique devient complexe, il n'est absolument pas certain que la store proc soit plus rapide. Mais bon, ok de manière générale.

2- Pas de DBA avec les ORM ? Là je ne suis pas du tout d'accord et si tu penses cela tu as tout faux. Je suis défenseur des ORM mais je n'oublie pas que la création d'un bon schéma physique est une des clé du succès. Et faire un bon schéma de base ne peut pas se faire sans connaissance approfondie de la base utilisée et donc d'une compétence "DBA".

[wiztricks]

Ouhla

2- Pas de DBA avec les ORM ? Là je ne suis pas du tout d'accord et si tu penses cela tu as tout faux. Je suis défenseur des ORM mais je n'oublie pas que la création d'un bon schéma physique est une des clé du succès. Et faire un bon schéma de base ne peut pas se faire sans connaissance approfondie de la base utilisée et donc d'une compétence "DBA".

N'ai je pas précisé:

Problèmes:

1. Faire des choses compliquées sans DBA,

Si le but de la discussion est de rebondir sur des choses qui n'ont pas été écrites, nous allons difficilement faire avancer le sujet.

En gros, ca reveint à dire que l'on est obligé de faire du propriétaire ou de faire n'importe quoi c'est un peu réducteur.

J'ai écris:

J'ai toujours un ORM mais les instances sont des lignes de tables: on limite un peu l'expressivité côté ORM. Mais la base de données ne se limite pas à un concept de persistance...

Se donner des possibilités pour fixer le curseur entre ce qui doit être fait en BDD et l'ORM n'oblige en rien à utiliser des technologies propriétaires. Et effectivement, ca limite un peu ce qu'on peut faire avec un ORM mais c'est peut être un choix pour faire vite pas cher et scalable.

L'ORM est le principe d'avoir un design drivé par les objets

Un principe comme un pattern a un domaine de validité.
L'ORM peut être une option de principe pour les petites applications, mais si vous voulez avoir un truc "scalable", vous serez obligé d'utiliser les possibilités que vous donnent toutes les ressources à votre disposition.

-W

[B.AF]

Je ne vois pas en quoi l'ORM doit être réservé aux petites applications..4

Moi pour le dire en une phrase, je suis prodigieusement sidéré de voir autant de personnes parler d'un sujet avec SQLPro en tête qu'elles ne maitrisent absolument pas.C'est effarant le volume de fausse vérité qui sort de ce débat.

[wiztricks]

Je ne vois pas en quoi l'ORM doit être réservé aux petites applications..

Si vous lisez honnêtement ce que j'ai écris, vous constaterez que j'ai pris la peine de dire que les ORM permettaient de construire rapidement de petites applications sans DBA, i.e. sans attention particulière aux optimisations que pouvaient apporter la BDD.

Dès qu'on se lance dans des choses compliquées, on peut utiliser un ORM mais comme il faut tenir compte des spécificités de la BDD.
L'adaptation d'impédance à faire entre ORM et modèle relationnel augmentait la complexité du projet... Et difficile de faire l'impasse sur le DBA.

Moi pour le dire en une phrase, je suis prodigieusement sidéré de voir autant de personnes parler d'un sujet avec SQLPro en tête qu'elles ne maitrisent absolument pas.C'est effarant le volume de fausse vérité qui sort de ce débat.

Soit nous abordons la question sur la base de croyances et chaque camp tape sur l'autre en les traitants d'incompétents, de gros nuls ou de vieux c...
Mais je ne vois pas trop en quoi çà fait avancer le débat.

Soit on admet que chaque école à des avantages avérés dans des cas particuliers. J'ai essayé de vous en proposer certains en précisant les propriétés ou le domaine de validité de ces cas.

- W

[_skip]

Moi pour le dire en une phrase, je suis prodigieusement sidéré de voir autant de personnes parler d'un sujet avec SQLPro en tête qu'elles ne maitrisent absolument pas.C'est effarant le volume de fausse vérité qui sort de ce débat.

Moi j'aimerai surtout qu'il vire de cet article la référence à IBatis car le citer ici c'est effectivement une méconnaissance grave de l'outil. C'est une erreur, ça arrive, mais faudrait pouvoir y remédier.

C'est un peu le but d'avoir un sujet feedback sur un article, de pouvoir discuter et repérer les éventuelles contre-vérités, et là malheureusement c'en est une.

[chaplin]

Soit on admet que chaque école à des avantages avérés dans des cas particuliers. J'ai essayé de vous en proposer certains en précisant les propriétés ou le domaine de validité de ces cas.

- W

Et LINQ, comment peut-on le positionner dans le débat ?

[wiztricks]

Bonjour,

Et LINQ, comment peut-on le positionner dans le débat ?

Depuis 2/3 ans je navigue dans des eaux étranges d'un univers fort éloignés des terres Java et Microsoft que j'ai longuement fréquenté.

Mon avis ne peut être celui d'un praticien de LINQ, mais j'essaie seulement de le positionner dans le débat que nous avons ici.

LINQ n'est ni ORM ni SGDB mais plutôt outil d'aide au développement qui apporte une approche "originale"(1) pour relier code aux données.

Il s'adresse aux programmeurs ou plutôt à leur productivité voire qualité du code produit.

Je n'ai sans doute pas tout compris, mais il semble intéresser plutôt la productivité du programmeur .NET qui écrit en VB ou en C# ou il y a un patrimoine et des savoir faire hérité des architectures 2-Tiers.

Comme je fais pas mal de réhabilitation, j'ai souvent à faire à ces vieux codes. Quand on regarde les dégats qu'ils ont subit avec le temps et la créativité dont ont du faire preuve les bâtisseurs originaux pour construire des trucs pas trop pourris dans sur ce genre d'architecture...

LINQ semble apporter des réponses, des aides... qui semblent intéressantes.

Le sont-elles effectivement? Mon manque d'expérience sur ces technos ne me permet pas d'avoir un avis 'informé'.

Ceci dit par rapport au scale up, je ne vois pas en quoi LINQ pourrait aider à réduire le nombre de compétences à mettre à contribution pour réaliser du "scalable" ou du "compliqué".

- W

(1) Avec un ORM entre le code et la persistance, le besoin d'un équivalent de LINQ (au sens relier code aux données) me semble assez limité.
En gros, l'ORM met le programmeur dans un univers cohérent et Eclipse n'a pas grand chose à faire pour faire la mise en correspondance.
LINQ peut apporter beaucoup au programmeur VB tout en faisant dire beurk au programmeur Java. Et réciproquement, le programmeur Java avec son ORM aura les plus grandes peines du monde à s'intégrer dans un existant 2 Tiers contrairement à LINQ.

[davcha]

Linq n'est rien d'autre qu'un système permettant de composer des programmes écrits dans un langage fonctionnel.

L'avantage est qu'après, le programme peut être manipulé de diverses manières pour le transformer en autre chose (du SQL, par exemple) ou pour extraire diverses parties du code pour en faire quelque chose de particulier, ce qui peut améliorer la robustesse du code, là où habituellement on devrait s'en remettre à des méthodes plus merdiques, comme l'usage de strings.

[B.AF]

Moi j'aimerai surtout qu'il vire de cet article la référence à IBatis car le citer ici c'est effectivement une méconnaissance grave de l'outil. C'est une erreur, ça arrive, mais faudrait pouvoir y remédier.

C'est un peu le but d'avoir un sujet feedback sur un article, de pouvoir discuter et repérer les éventuelles contre-vérités, et là malheureusement c'en est une.

Ca ne me générait pas si tout n'était entiérement faux, exagéré et méconnu.
Et le pire c'est qu'au final tous ces avis "pauvres" ne font qu'entretenir un clivage inutile puisque personne ne peut trouver ici un "best-practice".

[B.AF]

Si vous lisez honnêtement ce que j'ai écris, vous constaterez que j'ai pris la peine de dire que les ORM permettaient de construire rapidement de petites applications sans DBA, i.e. sans attention particulière aux optimisations que pouvaient apporter la BDD.

Dès qu'on se lance dans des choses compliquées, on peut utiliser un ORM mais comme il faut tenir compte des spécificités de la BDD.
L'adaptation d'impédance à faire entre ORM et modèle relationnel augmentait la complexité du projet... Et difficile de faire l'impasse sur le DBA.



Soit nous abordons la question sur la base de croyances et chaque camp tape sur l'autre en les traitants d'incompétents, de gros nuls ou de vieux c...
Mais je ne vois pas trop en quoi çà fait avancer le débat.

Soit on admet que chaque école à des avantages avérés dans des cas particuliers. J'ai essayé de vous en proposer certains en précisant les propriétés ou le domaine de validité de ces cas.

- W

Je suis encore désolé, mais tout est faux. Il ne peut pas y avoir d'école dont on puisse accepter les théories quand celles-ci aboutissent inéluctablement à un appauvrissement des compêtences et un risque opérationnel de production.

Dans ce sujet, et dont l'initiateur, je ne lis que des non-sens.

[Luc Orient]

Je suis encore désolé, mais tout est faux. Il ne peut pas y avoir d'école dont on puisse accepter les théories quand celles-ci aboutissent inéluctablement à un appauvrissement des compêtences et un risque opérationnel de production.

C'est le genre d'affirmation péremptoire qui gagnerait à être démontrée ou pour le moins illustrée.

Dans ce sujet, et dont l'initiateur, je ne lis que des non-sens.

L'inititiateur du sujet ne fait pas toujours dans la nuance, j'en conviens ... Cependant, on ne peut lui nier sa triple position publique de consultant, d'auteur et d'enseignant. Ses avis, parfois tranchés, s'appuient cependant sur des experiences concrètes de terrain.

[captainKirk]

Je suis d'accord avec la métaphore mais, dans ce débat, nous sommes il y a tension entre (au moins) deux aspects complètement différents:

• Des traitements plus près des données que permettent les Stored Procedures ont des atouts côté performances indiscutable (lié à la vitesse finie de la lumière)
• Un ORM permet de faire vite et pas cher (en se passant de DBA), c'est indéniable.

- W

Je voulais juste dire que l'un n'empêche pas l'autre, l'équilibre nécessite de trouver le juste milieu

[B.AF]

C'est le genre d'affirmation péremptoire qui gagnerait à être démontrée ou pour le moins illustrée.


L'inititiateur du sujet ne fait pas toujours dans la nuance, j'en conviens ... Cependant, on ne peut lui nier sa triple position publique de consultant, d'auteur et d'enseignant. Ses avis, parfois tranchés, s'appuient cependant sur des experiences concrètes de terrain.

Ce n'est pas une raison pour dire un telle paquet de fausses informations. Au contraire, c'est inquiétant. Et désolé si son "background" ne m'impressionne pas plus que ça.

[B.AF]

Vu que ma réponse se doit d'être détaillée; je reproche globalement les éléments suivants :

Une méconnaissance globale de pattern ORM
il ne s'agit "que" d'un pattern de développement. Le critiquer n'a pas de sens, puisqu'en fait l'élément de critique est souvent le framework qui implémente ce framework.
Le raisonnement du pattern est justement d'inverser la dépendance des objets au modéle relationnel dans les domaines applicatifs utilisant une DB.
Ce pattern n'a jamais préconisé la persistance ignorence par l'ignorance tout court de tout principe SQL.

Une mélange des pattern d'accès à la Db
Utiliser un ORM ne veut pas dire perdre la main sur la transaction, perdre la main sur la DB, une fois de plus le propos et d'utiliser une modelisation object plutôt que relationnel. La seule réalité concrête de ce pattern est que les objets sont le plus "simples" possibles et n'ont aucune relation directe à la DB. A la différence par exemple d'un pattern active record. certaines implémentation Active Record utilisent un framework ORM mais c'est une question d'ingenierie et pas d'outils.

Un mélange des responsabilités
Générer du code, implémenter une convention de gestion des modéles relationnels, l'utilisation des specificités de tel ou tel SGBD, l'utilisation de stratégies de chargement ou d'objets de Db (triggers, sp, vues..) est une décision qui n'est pas imposé par l'usage de l'ORM. Elle demeure de la responsabilité humaine. Quand on choisi de générer du code sans gérer l'intégrité relationnelle de la Db à priori, il s'agit plus d'incompêtence que d'une problèmatique d'ORM. Appeller une procédure stockée mal écrite sur des tables ne disposant pas de contrôle d'intégrité et éventuellement de triggers est aussi dangereux dans le résultat.

Une méconnaissance profonde des Frameworks existants
La plupart des frameworks existants disposent de fondamentaux solides sur les aspects suivants :
- Gestion du versioning
- Gestion des transactions business
- Gestion d'un specialisation du moteur (oracle, sql server...)
- Gestion d'une bibliothéque de requête
- Accès direct à la DB
- Gestion du Unit Of Work
- Gestion d'un cache de données / requêtes
- Audit clair et détaillé des accès en base

il faut y comprendre que l'utilisation judicieuse d'un ORM permet :
- De réduire le nombre d'instructions émises (update si nécessaire et pas inconditionnel, select si l'objet n'est pas déjà en cache...)
- D'avoir une approche multi base / sharding en délocalisant les transactions au niveau middleware, et en laissant la transaction technique dans le moteur Db le cas échéant, ce qui est excellent dans une approche service
- De suivre à la ligne le SQL émis et de permettre justement une vraie optimisation et gestion des modéles
- D'implémenter des contraintes DB spécifiques à l'environnement à faible coût et systèmatiques (check, triggers, sp, relations...)
- D'implémenter une vraie stratègie de tests (unit & acceptance) sur les processus de DB

Un mélange entre technique et besoin
L'ORM n'est pas la silver bullet du dev. Il existe des cas où l'ORM n'est pas la bonne réponse. Il existe aussi des cas où le SGBD n'est pas la bonne réponse.
L'ORM est principalement une bonne solution pour réaliser une architecture SOA avec des graphs objets maitrisés.Pour le reste, c'est une appréciation qui reste personnelle

Un mélange entre réalité de l'ORM et usage
L'ORM souffre du maux de la génération de code. La génération de code fait du mal à priori car les questions se posent en termes relationnels, qui sont rarement bons (expertises SQL non sollicitées), les générateurs ne sont pas intelligents et ne peuvent déterminer l'utilité métier d'un graph objet ni affiner une stratégie de chargement. Arrive des modéles objets démentiels, pouvant émettre des requêtes de plus de 400 lignes provoquant des goulets d'étranglement. Cette problèmatique est un problème de connaissance et de formation, pas un problème d'outil. La finalité est la même qu'un développeur utilisant des requêtes SQL sans maitriser le SQL : une cata. Elle n'a cependant pas à jetter l'oprobe sur un pattern utile et fiable si maitrisé.
L'ORM est mal employé aujourd'hui OUI; il est confondu avec l'Active Record et le Data Access Layer OUI.

L'oubli de sa finalité et la méconnaissance du persistence ignorance
L'ORM peut persister ...partout ! Il ne sert pas qu'à persister de la DB.
Il ne s'agit pas d'un pattern destiné à résoudre la sauvegarde d'un objet dans une table, mais de résoudre la persistence d'un domaine applicatif quelque soit le support de persistence (fichier, rdb, odb,kvs, ...) en apportant la simplification suivante :

• Le développeur se concentre sur les objets et les services
• La couche technique se concentre sur la persistance et les transactions

Il est clairement impossible de maitriser et d'utiliser un ORM sans avoir ces fondamentaux à l'esprit.

La négligence des vrais apports
- Un modéle objet unique, une couche de services pensée, une politique de test adéquate
- Un dialogue plus proche et plus efficace entre différents métiers
- Une évolutivité et un développement en couche

Enfoncer des portes ouvertes
Evidemment que les performances ne peuvent égaler celles du SQL pur dans le moteur du SGB. De même que l'utilisation d'objets d'un langage quelconque font aussi perdre en performances entre la réquête et sa visualisation ultime par l'utilisateur de l'application.
Il est très facile sans ORM d'obtenir dans du code des performances inférieures, voir même en SQL. Là n'est pas le propos, l'importance, c'est de connaitres ces faits et d'en tenir compte au moment du design. Le SELECT émis par un Fmk ORM ne prend pas plus de temps que le SELECT rentré dans la console du debugger.
Il existe des usages pour lesquels l'ORM n'est pas approprié (batchs). L'ORM est approprié pour des traitements objets unitaires et offre une qualité et une testabilité de code largement supérieure à celle qu'offre le SQL.
Avoir une raisonnement pro ou anti a autant de sens que d'avoir un raisonnement sans nuance : le risque de se tromper un jour existe.

Maitrise des sous jacents
Qui dit ORM dit multiples langages et autres principes :
- AOP
Utilisé pour les stratégies de chargement, les interceptions
- Objet
Utile de maitriser les principes de design d'interface, d'héritage, d'abstraction, d'attributs
- Métadonnées
La programmation par attributs est utile à la spécification du comportement relationnel d'un objet
- IOC
Comprendre comment le framework fait abstraction du SGBD. Est-ce un langage ? Une API ?????
- SQL et SGBD
Comprendre les principes du SGBD et les règles élementaires, appliquer des formes normales, des données de test pour vérifier les montées en charge...
- Framework
Il faut comprendre et se former sur le framework utilisé. Tous les ORM sont une implémentation particuliére, et chacun a son principe de fonctionnement justifiable mais singulier.