Patron d'architecture

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

En informatique, un patron d'architecture est un patron de conception, c'est-à-dire un modèle de référence qui sert de source d'inspiration lors de la conception de l'architecture d'un système ou d'un logiciel informatique en sous-é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 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 le map. Ce pattern permet de créer un cache pour les objets dans la base de données.

Lazy Load (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 celle dont il a besoin. Ce pattern est utile lorsqu'il faut faire des appels sur 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 ligne d'une table avec plusieurs ligne 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]

Représente dans hiérarchie d'héritage entre les classes où chaque ligne de la table va représenter une classe et chaque colonne un objet.

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 changement 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 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]

  • Toute les colonnes sont fiables, facile à comprendre et ne gâche 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éder en continue
  • 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.

Annexes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

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