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
[modifier | modifier le code]Unit of work (travail atomique)
[modifier | modifier le code]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)
[modifier | modifier le code]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)
[modifier | modifier le code]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)
[modifier | modifier le code]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)
[modifier | modifier le code]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)
[modifier | modifier le code]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)
[modifier | modifier le code]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)
[modifier | modifier le code]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)
[modifier | modifier le code]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
[modifier | modifier le code]- 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
[modifier | modifier le code]- 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)
[modifier | modifier le code]Représente en une hiérarchie de classe héritée où chaque table représente une classe.
Forces
[modifier | modifier le code]- 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
[modifier | modifier le code]- 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)
[modifier | modifier le code]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
[modifier | modifier le code]- Christopher Alexander, Sara Ishikawa et Murray Silverstein, A pattern language: towns, buildings, construction, Oxford University Press, (ISBN 978-0-19-501919-3)
Voir aussi
[modifier | modifier le code]Articles connexes
[modifier | modifier le code]Bibliographie
[modifier | modifier le code]- Christopher Alexander et al., A Pattern Language, Oxford University Press, 1977
- Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2013
