Sécurité des systèmes informatiques/Sécurité informatique/Eléments de législation

Auto-éditer un wikilivre/addappendix/addappendix.pot

.\addappendix.pot
Auto-éditer un wikilivre/addappendixaddappendix.pot

Patrons de conception/Logique du domaine

Les patrons de logique du domaine permettent de gérer la logique dans les applications métier.
Les différents patrons de logique du domaine sont les suivants :

Patrons de conception/Script de transaction

La plupart des applications métier peuvent être organisées comme une série de transactions.
Une transaction peut voir des informations comme organisées d'une manière particulière, une autre y apportera des modifications.
Chaque interaction entre un système client et un serveur contient une certaine logique qui dans certains cas peut être aussi simple qu'afficher une information de la base de données. Dans d'autres cas, cela peut impliquer plusieurs étapes de calculs et validations.
Un script de transaction organise toute cette logique basiquement comme une seule procédure, effectuant des appels directs à la base de données ou à travers une mince couche d'encapsulation.
Chaque transaction aura son propre script de transaction, toutefois les tâches fréquentes peuvent être divisées en sous-procédures.

Patrons de conception/Modèle du domaine
La logique métier peut être très complexe, décrivant des règles et une logique compliquées.
Les objets permettent de gérer cette complexité.
Un modèle du domaine crée un ensemble d'objets interconnectés où chaque objet représente une entité significative, quelle soit grande comme une entreprise ou petite comme une ligne de bon de commande.

Patrons de conception/Module de table
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.

Patrons de conception/Couche de service
Les applications d'entreprise requièrent typiquement différents types d'interfaces aux données qu'elles stockent et aux logiques qu'elles implémentent : chargeurs de données, interfaces utilisateur, passerelle d'intégration etc.
En dépit de leur différent buts, ces interfaces ont souvent besoin d'interactions communes avec l'application pour accéder et manipuler ses données et appeler la logique métier.
Les interactions peuvent être complexes, impliquant des transactions à travers beaucoup de ressources et la coordination de nombreuses réponses à une action.
Encoder la logique des interactions séparément dans chaque interface provoque beaucoup de duplication de code.
Une couche de service définit les frontières d'une application et son ensemble d'opérations disponibles du point de vue de l'interface des couches client.
Elle encapsule la logique métier de l'application, contrôle les transactions et coordonne les réponses dans la mise en œuvre de ses opérations.

Étude de texte sur la différence entre l'homme et l'animal à l'état de nature

Commentaire philosophique
Ce livre s'adresse aux élèves de terminales, mais il peut étendre son public.
On y trouve des exemples d'explications de textes.

Patrons de conception/Architecture de source de données

Les patrons d'architecture de source de données définissent des structures pour la gestion des sources de données.
Les différents patrons d'architecture de source de données sont les suivants :

Patrons de conception/Passerelle de table de données

Mélanger des requêtes SQL à la logique d'une application peut causer beaucoup de problèmes.
Beaucoup de développeurs ne sont pas à l'aise avec SQL et ceux qui le sont peuvent ne pas écrire de requêtes correctement.
Les administrateurs de base de données ont besoin d'être capable de trouver les requêtes SQL facilement afin de pouvoir comprendre comment ajuster et faire évoluer la base de données.
Une passerelle de table de données agit comme une passerelle à une table d'une base de données.
Une instance détient et gère toutes les lignes d'une table ou d'une vue et y accède avec différentes opérations : sélection, insertion, mise à jour et suppression.
Le reste du code appelle ses méthodes pour toutes les interactions avec la base de données.

Patrons de conception/Passerelle de ligne de données

Introduire du code d'accès à une base de données dans les objets en mémoire génère quelques inconvénients.
Le premier concerne les objets ayant leur propre logique métier : l'ajout de code manipulant la base de données augmente la complexité.
Également, il est plus difficile d'effectuer des tests lorsque les objets sont liés à une base de données ; les tests sont plus lent à exécuter à cause de tous les accès à la base de données.
Il peut être nécessaire d'accéder à plusieurs bases de données avec toutes ces petites variations ennuyeuses dans leur requêtes SQL.
Une passerelle de ligne de données produit des objets ressemblant exactement à l'enregistrement dans votre structure d'enregistrements mais qui sont accessibles avec les mécanismes habituels de votre langage de programmation.
Tous les détails d'accès à la source de données sont cachés derrière cette interface.

Patrons de conception/Enregistrement actif

Un objet contient à la fois les données et le comportement.
Beaucoup de ces données sont persistantes et doivent être stockées dans une base de données.
Un enregistrement actif utilise l'approche la plus évidente en plaçant la logique d'accès aux données dans l'objet métier.
De cette manière, tout le monde sait comment lire et écrire leurs données depuis et vers la base de données.

Patrons de conception/Gestion de données