Patron d'architecture

Un patron d'architecture est une solution générale et réutilisable à un problème d'architecture récurrent^[1]. En informatique, les patrons d'architecture sont semblables aux patrons de conception mais ont une portée plus large. Ils servent de modèle de référence et de source d'inspiration lors de la conception de l'architecture d'un système ou d'un logiciel informatique, pour décomposer celui-ci en éléments plus simples.

Exemples de patron d'architecture

Unit of work (travail atomique)

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.

Identity map (map d'identification)

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.

Lazy loading (chargement fainéant)

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.

Identity field (champ d'identification)

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.

Foreign key mapping (mapping de clé externe)

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.

Association table mapping (mapping de tables associées)

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.

Dependant mapping (mapping de dépendance)

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.

Serialized large object (sérialisation de gros objets)

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.

Single table inheritance (héritage d'une table unique)

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.

Forces

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

Faiblesses

Les champs ne sont pas toujours fiables, ce qui peut poser un 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.

Class table inheritance (héritage d'une table par classe)

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

Forces

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

Faiblesses

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.

Repository (répertoire)

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.

Références

↑ Christopher Alexander, Sara Ishikawa et Murray Silverstein, A pattern language: towns, buildings, construction, Oxford University Press, 1977 (ISBN 978-0-19-501919-3)

Voir aussi

Articles connexes

Bibliographie

Christopher Alexander et al., A Pattern Language, Oxford University Press, 1977
Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2013

Portail de l’informatique

[1] Christopher Alexander, Sara Ishikawa et Murray Silverstein, A pattern language: towns, buildings, construction, Oxford University Press, 1977 (ISBN 978-0-19-501919-3)

[1]