grimboite/old/index.md

2.1 KiB

Object Relational Mapping

La persistance et l'accès à une base de données est une chose simple à faire, dans le sens où on veut souvent sauver ses données pour pouvoir les récupérer par la suite. Jusque là, rien de très compliqué. De plus, il existe énormément de solutions pour ce problème:

  • Sauver les informations dans des fichiers texte ou XML
  • Utiliser une base de données relationnelle, utilisée par un et un seul utilisateur (SQLite, SQLCe)
  • Une base de données relationnelle multi-utilisateurs (PostgreSQL, SQL Server, Oracle, MariaDB)
  • Une base de données orientée documents (MongoDB, RavenDB, Cassandra)

Bref, les solutions existent et dépendent beaucoup du contexte et ce qu'on souhaite faire. Le problème de correspondance entre le modèle objet et les informations stockées en base reste par contre entier: quel design pattern doit-on utiliser pour garder la persistance de nos données?

Parmi les patterns existants, il existe notamment :

  • Active Record
  • Data Mapper

En plus de tout ceci, il convient également de faire attention au Lazy Loading... Bref, c'est un beau bordel.

Avec Active Record, chaque objet est responsable de sa propre persistance. Chaque classe aurait donc un équivalent des méthodes suivantes : Save(), Delete(), Insert() et Find().

Avec le pattern Data Mapper, on a en fait un modèle métier qui diffère de ce qui est représenté par la base de données. On a donc (généralement) une classe intermédiaire qui permet de faire correspondre un champ du modèle à un champ de la base de données.

Sur cette base, il est possible d'utiliser des pattern type Repository et Identity Map (qui ne sont pas incompatibles l'un avec l'autre).

Domain Model

Le pattern Domain Model permet de représenter des objets qui définissent non seulement le contenu de la base de données, mais également le comportement de ceux-ci. C'est une manière de représenter l'information et d'y accéder.

Contrairement à d'autres patrons de conception, qui tendent à mieux séparer la couche logique de la couche d'accès aux données, ce patron-ci fusionne les deux.