Patron d'architecture

Gère une liste d'objets durant une transaction et permet de gérer l'écriture des changements ainsi que les problèmes de concurrence.

Charge en une seule fois tous les objets dans un map. Les objets sont ensuite retrouvés via la map. Ce pattern permet de créer un cache pour les objets dans la base de données.

Crée un objet qui ne récupère pas toutes les données qui lui sont associées mais qui peut récupérer seulement celles dont il a besoin. Ce pattern est utile lorsqu'il faut faire des appels à une ou plusieurs base de données.

Sauvegarde l'identifiant d'un champ dans un objet afin de maintenir une unité entre l'objet contenu en mémoire et une ligne dans une base de données. Ce pattern est utile lorsqu'il y a un mapping entre les objets en mémoire et les lignes d'une base de données.

Map un objet avec une clé qui sert de référence entre différentes tables. Ce pattern peut être utilisé pour tous les cas où il n'y a qu'un seul champ qui sert d'identifiant entre les tables.

Sauve l'association de plusieurs lignes d'une table avec plusieurs lignes d'une autre table lorsque cette association est représentée dans la base de données par une troisième table. Ce pattern est très utile pour représenter une relation Many-to-many entre deux tables dans une base de données.

Crée une relation d'héritage dans les objets créés à partir de la base de données. Ce pattern est utile lorsqu'une table comporte plusieurs références vers d'autres tables mais que ces tables ne comportent pas de référence vers la première, on a donc un système de référence dans un sens qui est représenté dans ce pattern sous forme d'héritage.

Sauvegarde dans un gros objet par sérialisation à partir d'un champ d'une base de données un graphe d'objets. Ce pattern est très utile pour les données représentées en XML mais présente des faiblesses lorsqu'il faut utiliser du SQL car il ne permet pas de faire des requêtes SQL.

L'ensemble des classes héritées sont enregistrées dans une seule table. Chaque ligne représente un objet. Une colonne supplémentaire contenant un détrompeur (souvent le nom de la classe fille) doit être ajoutée.

• Une seule table à gérer dans la base de données
• Il n'y a pas de jointure à faire pour retrouver les données
• Les changements dans la hiérarchie des champs n'affectent pas la base de données

• Les champs ne sont pas toujours fiables, ce qui peut poser problème lors de l'utilisation directe des tables.
• Les colonnes qui en sont utilisées que par quelques sous-classes participent au gâchis de la mémoire.
• Une seule table peut finir par devenir trop grosse ce qui diminuera les performances.
• Il n'y qu'un seul nom possible par champ car cela correspondra au nom de la classe.

Représente en une hiérarchie de classe héritée où chaque table représente une classe.

• Toutes les colonnes sont fiables, faciles à comprendre et ne gâchent pas d'espace
• La relation entre la mémoire et la base de données est très simple

• Pour accéder à plusieurs tables, il est nécessaire de faire des jointures
• Tout changement dans les champs implique un refactoring de la base de données
• La classe mère risque de devenir un goulot d'étranglement à force d'être accédé en continu
• La normalisation peut rendre compliqué le pattern pour des requêtes ad-hoc.

Crée un lien entre le domaine et la couche de donnée en utilisant une collection d'interface afin d'accéder aux objets du domaine. Ce pattern est utile lorsque la complexité du domaine est élevée. Cela permet d'isoler le domaine de la couche de données. Sur de gros systèmes avec beaucoup d'objets et de requêtes, cela réduit le code pour écrire toutes les requêtes. Cela permet de coder le reste de l'application sans penser aux requêtes pour accéder à la base de données.

• Architecture logicielle
• Architecture en couches
• Entity-control-boundary
• Architecture hexagonale

• Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2013