L’ORM serait-il une « grosse erreur » ?

**Amine Horseman** · 24/12/2014, 03h31

L’ORM serait-il une « grosse erreur » ?
Selon un développeur, « l’ORM est un anti-pattern qui ne devrait pas exister »

Il existe plusieurs design patterns utilisés dans la programmation orientée objet, et certains tellement utilisés qu’ils deviennent presque incontournables lorsqu’on veut apprendre le développement. L’Object Relationnal Mapping (ORM) est l’un de ces patterns à succès. Il permet d’accéder à une base de données relationnelle à partir d’objets. On peut le résumer comme une technique qui crée l’illusion d’une base de données orientée objet à partir d’une base de données relationnelle.

Ce modèle est implémenté dans plusieurs langages de programmation aujourd’hui à tel point qu’il devient une référence dans les livres. Toutefois, dans un article, Yegor Bugayenko, Directeur de technologie à Teamed.io, déclare que « l’ORM est un anti-pattern terrible qui viole tous les principes de la programmation orientée objet ».

Ce n’est pas la première fois que quelqu’un critique l’ORM. Le débat est long et ne date pas d'hier. On lui avait déjà reproché d’être techniquement limité, faible en performances et difficile à apprendre. Toutefois, pour Yegor Bugayenko, l'idée derrière l’ORM est fausse. Selon lui, « son invention était peut-être la deuxième grosse erreur en POO après la référence NULL ».

La raison qu’il donne est simple ; au lieu d’encapsuler l’interaction avec la base de données dans un objet et fournir par conséquent un point d'entrée unique, il fait l’inverse : il définit les routines qui permettent de communiquer avec la base dans l’objet ORM tandis que les données sont extraites « dans la chose que nous ne pouvons même pas appeler un objet ». Ce qui rend la détection des erreurs plus difficile. Mais en plus, « le SQL n’est pas caché » ce qui ajoute au programmeur la contrainte d’en connaître la syntaxe.

Figure : comparaison entre 1) technique utilisée par l'ORM, 2) technique utilisée par les SQL-speaking objects

Selon lui, la solution serait d’encapsuler le tout dans un seul et même objet (comme décrit dans la figure). Cet objet, que Yegor Bugayenko appelle « SQL-speaking object », sera en charge de toutes les opérations et permettra de cacher tous les détails de la communication avec la base de données : « Il n'y a pas de transactions, pas de sessions ou de factories. Nous ne savons même pas si ces objets sont en train de parler avec la base de données ou s’ils gardent toutes les données dans des fichiers textes ».

Dans son article, il présente quelques exemples en insistant sur le fait que les SQL-speaking objects sont plus simples et respectent de loin les principes de l’orienté objet, à l’inverse de l’ORM « qui ne devrait exister dans aucune application, que ce soit une petite application web ou un gros système pour entreprise ».

Source : DZone

Et vous ?

Êtes-vous d’accord avec l’avis de Yegor Bugayenko ? Pourquoi ?

**Gugelhupf** · 24/12/2014, 10h30

Je n'ai pas tout à fait compris l'intérêt de l'article publié par Bugayengo.

Certes les ORM (je pense à l'approche JPA en particulier) :

apportent une surcouche qui ralentit le programme.
génèrent des requêtes SQL parfois aberrantes quand on observe au niveau débug.
ont pas mal de spécificités (notamment la gestion des transactions, quoi que... en activant le mode JTA on peut se passer des transactions)
ne sont pas adaptés pour créer des batchs
ne sont pas adaptés pour écrire des requêtes SELECT complexes

... mais pour une application web de gestion ou un blog par exemple, ils simplifient grandement l'écriture du code pour des opérations de types INSERT/UPDATE/DELETE et les SELECT simples.

L'auteur crée la méthode suivante pour insérer un objet de type Post dans sa base :

Code :

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

1
2
3
4
5
6
7
8
9
10
  public Post add(Date date, String title) {
    return new PgPost(
      this.dbase,
      new JdbcSession(this.dbase)
        .sql("INSERT INTO post (date, title) VALUES (?, ?)")
        .set(new Utc(date))
        .set(title)
        .insert(new SingleOutcome<Integer>(Integer.class))
    );
  }

En utilisant un ORM je fais juste ceci :

Code :

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

em.persist(monPgPost);

L'auteur crée la méthode suivante qui retourne un iterable pour récupérer tous les objets de type Post dans sa base :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  public Iterable<Post> iterate() {
    return new JdbcSession(this.dbase)
      .sql("SELECT id FROM post")
      .select(
        new ListOutcome<Post>(
          new ListOutcome.Mapping<Post>() {
            @Override
            public Post map(final ResultSet rset) {
              return new PgPost(rset.getInteger(1));
            }
          }
        )
      );
  }

Je ne vois pas l'intérêt de récupérer tous les éléments d'une table, par contre en utilisant un ORM je peux récupérer un objet en particulier comme ceci :

Code :

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

Post post = em.find(Post.class, monId);

**dfiad77pro** · 24/12/2014, 11h45

Un ORM (je pense à Entity Framework que je connais mieux)
peut aussi être utilisé conjointement avec d'autre méthodes ( proc stockée, etc.).

On est même pas obliger d'utiliser la persistance tout le temps.

J'ai de nombreux projets à flux importants qui utilisent un ORM et ne sont pas lents...
Cela dit un ORM nécessite beaucoup d'expérience pour être utilisé de manière optimale dans une architecture complexe.
Sa simplicité apparente est un leurre.

Dire qu'une Techno est Anti-Patern, sans proposer mieux, c'est l'excuse à la mode

( je l'entends souvent de la part des dev Java à propos de C# sur les méthodes d'extension et Linq

)

**Logan Mauzaize** · 24/12/2014, 12h08

Génial, il propose l'idée de tout recoder à la main ?
Je vois rien dans ce qu'il propose qui est une réelle différence avec le système actuel à part que le sien est complétement "figé" et lie complétement l'interface avec son interface de communication avec la base de données. Mais attendez .... ca ressemblerait pas à JPA avec les annotations ?

Franchement quit à faire du SQL, autant partir sur MyBatis. Apache Cayenne me semble également intéressant mais je n'ai pas eu l'occasion de le mettre en pratique.

Bon lisons l'article, "ne jugeons pas un livre à sa couverture" m'a-t-on dit.