Mapping objet-relationnel

L'utilisation de la programmation orientée objet avec une base de données relationnelle nécessite de convertir les données relationnelles en objets et vice-versa. Ceci conduit à programmer cette conversion pour chaque objet et donc à dupliquer énormément de code similaire.

Illustration de code Java qui utilise l'API JDBC sans ORM pour récupérer les données relationnelles d'un client (customer en anglais) afin de les transformer en un objet Java :

public Customer loadCustomer(long customerId, Connection connection) {
    if (0 == customerId || connection == null) {
        return null;
    }
 
    PreparedStatement statement = null;
    try {
        // préparation de la requête à la base de données
        statement = connection.prepareStatement(
                " SELECT CUSTOMER_ID, CUSTOMER_NAME, CUSTOMER_ADDRESS "
                + " FROM CUSTOMER WHERE CUSTOMER_ID = ? ");
        statement.setLong(1, customerId);
        ResultSet resultSet = statement.executeQuery();
        if (resultSet.next()) {
            // transformation des données relationnelles en objet "Customer"
            Customer customer = new Customer();
            int index = 1;
            customer.setCustomerId(resultSet.getLong(index++));
            customer.setCustomerName(resultSet.getString(index++));
            customer.setCustomerAddress(resultSet.getString(index++));
            return customer;
        }
    } catch (final Exception e) {
        log.info("", e);
    } finally {
        // nettoyage
        if (statement != null) {
            try {
                statement.close();
            } catch (final SQLException e) {
                log.info("", e);
            }
        }
    }
    return null;
}

Un code source très similaire sera à saisir pour récupérer les informations des autres tables et les transformer en objets. Les parties du code qui changent sont : le SQL, l'affectation des paramètres sur l'objet PreparedStatement et la récupération des résultats et leur affectation sur l'objet. La structure générale du code reste toujours la même.

En fait, le code permettant de réaliser toutes les opérations de CRUD (création, lecture, mise à jour, suppression) se ressemble énormément d'une table à l'autre et d'un objet à l'autre.

Les frameworks de mapping objet-relationnel permettent d'éliminer la duplication de code dans les opérations CRUD.

Le mapping objet-relationnel consiste à déclarer une association entre une (ou plusieurs) classes et une table, et chaque attribut de la classe avec un champ de la table associée. Par exemple, la classe Customer sera associée à la table CUSTOMER, et les attributs associés comme suit :

• Customer ≈ CUSTOMER :
  • Customer.customerId est associée avec CUSTOMER.CUSTOMER_ID
  • Customer.customerName est associée avec CUSTOMER.CUSTOMER_NAME
  • Customer.customerAddress est associée avec CUSTOMER.CUSTOMER_ADDRESS

Un fichier texte peut alors être créé pour déclarer et décrire en bloc de telles mises en correspondance sur un ensemble de classes et tables du modèle. Lorsque le langage le permet (Java par exemple), il est même possible d'utiliser l'introspection pour récupérer les informations sur les attributs lors de l'exécution (type, valeur, etc.) et pouvoir construire dynamiquement les requêtes SQL de type CRUD. Des mécanismes similaires existent pour les autres langages disposant de frameworks de mapping objet-relationnel.

Le résultat finit par simuler une base de données "objet" "virtuelle", qui peut être utilisée au sein du langage de programmation sans référencer directement le SGBD sous-jacent.

Il y a des avantages et des inconvénients à l'utilisation d'ORM.

L'un des avantages est que cela réduit la quantité de code qui doit être écrit et permet une homogénéité avec le reste du code pour les langages orientés objets.

Cependant, les ORM induisent une couche logicielle supplémentaire, ce qui peut nuire aux performances, et bien entendu à la maintenabilité. Par ailleurs, certains outils ORM ont historiquement montré des limites lors de la suppression de données en bloc.^{[réf. nécessaire]} En outre, une base de données mal conçue peut induire une forte dépendance à un système ORM, et réciproquement.^{[réf. nécessaire]}

Le mapping objet-relationnel est toutefois considéré en 2018 comme une méthode de programmation viable pour la traduction des données entre les systèmes de bases de données relationnelles et des langages de programmation orientés objet.

Il existe de nombreux outils d'ORM payants, gratuits ou même en licence libre.

Voici quelques frameworks de mapping objet-relationnel :

• Java
  • Java Persistence API
    • TopLink
      • EclipseLink
    • Apache OpenJPA
  • Hibernate
  • Spring Data
  • Java Data Objects
  • Apache Cayenne
  • OJB - Object Relational Bridge
  • Apache Torque
  • SimpleORM
  • iBATIS
  • Avaje Ebean
  • Grails
  • AJO
• .Net
  • CodeFluent Entities
  • Entity Framework[1]
  • NHibernate
  • Linq To SQL (.Net Framework 3.5)
  • iBATIS
  • Euss (Evaluant Universal Storage Services)
  • MyGeneration/dOOdads
  • LayerCake Generator (.NET Framework 4.5)
• Ruby
  • Active record
  • RBatis, portage de iBATIS en Ruby pour Ruby on Rails
  • Sequel
  • DataMapper
• PHP 5
  • RedBean
  • Doctrine
  • Pdomap
  • Phpmyobject
  • CakePhp
  • Propel
  • FoxOrm
  • AgileToolKit
  • Syrius
  • Fuelphp
  • Eloquent
• Python
  • SQLAlchemy
  • Peewee
  • SQLObject
  • Django
• Node.js
  • TypeORM
  • Mongoose
  • Sequelize
  • Prisma
• Delphi
  • Synopse mORMot framework
  • TMS Software's TMS Aurelius - commercial.
  • Delphi ORM - open source
• Perl
  • DBIx::Class
  • Rose::DB::Object
  • Class::DBI
• Rust
  • Diesel
  • RustOrm
• Elixir
  • Ecto

• Portail de la programmation informatique
• Portail des bases de données