# Patrons de conception/Module de table

* Introduction
* Patrons du « Gang of Four »
** Patrons de création
*** Singleton
*** Prototype
*** Fabrique
*** Fabrique abstraite
*** Monteur
** Patrons de structure
*** Pont
*** Façade
*** Adaptateur
*** Objet composite
*** Proxy
*** Poids-mouche
*** Décorateur
** Patrons de comportement
*** Chaîne de responsabilité
*** Commande
*** Interpréteur
*** Itérateur
*** Médiateur
*** Mémento
*** Observateur
*** État
*** Stratégie
*** Patron de méthode
*** Visiteur
* Patrons GRASP
** Expert en information
** Créateur
** Faible couplage
** Forte cohésion
** Contrôleur
** Polymorphisme
** Fabrication pure
** Indirection
** Protection
* Patrons d'entreprise
** Logique du domaine
*** Script de transaction
*** Modèle du domaine
*** Module de table
*** Couche de service
** Architecture de source de données
*** Passerelle de table de données
*** Passerelle de ligne de données
*** Enregistrement actif
*** Gestion de données
** Comportement objet-relationnel
*** Unité de travail
*** Carte d'identité
*** Chargement différé
** Structure objet-relationnel
** Association méta-données objet-relationnel
** Présentation web
** Distribution
** Concurrence locale (hors-ligne)
** État de session (Session State Patterns)
** Patrons de base
*** Passerelle (Gateway)
*** Mapper
*** Type de base pour la couche
*** Interface séparée
*** Registre
*** Plugin
*** Objet valeur
*** Monnaie
*** Cas spécial
*** Service de substitution
*** Ensemble d'enregistrements
* Autres patrons
** Type fantôme
** Double-dispatch
** Post-Redirect-Get
** Map-Reduce
** Évaluation retardée
** Copie sur modification
** Injection de dépendance
** Inversion de contrôle
** Modèle-Vue-Contrôleur
** Modèle-Vue-Présentateur
** Écart de génération
** Objet nul
** Objets réutilisables
** Outbox
** Feature toggles
* Bibliographie et liens
* Introduction
* Patrons du « Gang of Four »
** Patrons de création
*** Singleton
*** Prototype
*** Fabrique
*** Fabrique abstraite
*** Monteur
** Patrons de structure
*** Pont
*** Façade
*** Adaptateur
*** Objet composite
*** Proxy
*** Poids-mouche
*** Décorateur
** Patrons de comportement
*** Chaîne de responsabilité
*** Commande
*** Interpréteur
*** Itérateur
*** Médiateur
*** Mémento
*** Observateur
*** État
*** Stratégie
*** Patron de méthode
*** Visiteur
* Patrons GRASP
** Expert en information
** Créateur
** Faible couplage
** Forte cohésion
** Contrôleur
** Polymorphisme
** Fabrication pure
** Indirection
** Protection
* Patrons d'entreprise
** Logique du domaine
*** Script de transaction
*** Modèle du domaine
*** Module de table
*** Couche de service
** Architecture de source de données
*** Passerelle de table de données
*** Passerelle de ligne de données
*** Enregistrement actif
*** Gestion de données
** Comportement objet-relationnel
*** Unité de travail
*** Carte d'identité
*** Chargement différé
** Structure objet-relationnel
** Association méta-données objet-relationnel
** Présentation web
** Distribution
** Concurrence locale (hors-ligne)
** État de session (Session State Patterns)
** Patrons de base
*** Passerelle (Gateway)
*** Mapper
*** Type de base pour la couche
*** Interface séparée
*** Registre
*** Plugin
*** Objet valeur
*** Monnaie
*** Cas spécial
*** Service de substitution
*** Ensemble d'enregistrements
* Autres patrons
** Type fantôme
** Double-dispatch
** Post-Redirect-Get
** Map-Reduce
** Évaluation retardée
** Copie sur modification
** Injection de dépendance
** Inversion de contrôle
** Modèle-Vue-Contrôleur
** Modèle-Vue-Présentateur
** Écart de génération
** Objet nul
** Objets réutilisables
** Outbox
** Feature toggles
* Bibliographie et liens
[ Modifier le sommaire ]
Un des messages clés de l'orienté objet est l'encapsulation des données avec le comportement qui les utilisent. L'approche orientée objet traditionnelle est basée sur les objets avec identité, à l'instar du modèle de domaine. Ainsi, si nous avons une classe « employé », toute instance correspond à un employé particulier. Ce schéma fonctionne bien car en ayant une référence à un employé, nous pouvons exécuter des opérations, suivre les relations et collecter des données sur lui.
L'un des problèmes avec le modèle de domaine est l'interface avec les bases de données relationnelles. À bien des égards, cette approche traite la base de données relationnelle comme une entité ésotérique avec qui personne ne veut communiquer. En conséquence, vous avez souvent besoin d'une gymnastique de programmation considérable pour extraire des données de la base de données, en les transformant entre deux représentations différentes des données.
Un module de table organise la logique du domaine avec une classe par table dans la base de données, et une seule instance de la classe contient les diverses procédures agissant sur les données. La différence principale avec le modèle de domaine est, par exemple, que pour gérer plusieurs commandes, le modèle de domaine aura un objet par commande, tandis qu'un module de table aura un objet pour gérer toutes les commandes.