Styles architecturaux pour CRUD Flashcards
Quelles sont les deux extrémités de l’échelle de catégorisation des styles architecturaux du point de vue de ce qui nous intéresse (pas le nom du style)? Donner des exemples de cas d’utilisation pour chaque.
Data d’un côté: Formulaire, Traiter données en temps réel
Règles d’affaire (domaine riche) de l’autre: Soumission d’assurance, Impôts
Quels sont les styles architecturaux que l’on retrouve à chaque extrémité du spectre des styles architecturaux?
Data: CRUD
Riche: Hexagonal, DDD, Clean Architecture
Quels sont les styles architecturaux que l’on retrouve au milieu du spectre?
Glue System
ETL
Vrai ou faux. Notre problème d’affaire ne peut pas se trouver à plusieurs endroits sur le spectre de styles architecturaux?
Faux. Il peut avoir certaines parties se trouvant sur divers endroits dans le spectre (ex: Billetterie DDD, Profile CRUD)
Expliquez le style architectural centré sur la base de données.
Ce style architectural n’est que peu commun dans l’univers du paradigme orienté objet. En fait, il s’apparente plus au paradigme procédural.
En fait, la base de données devient le centre de notre application. Ce qui fait que chacune des actions de l’application n’a pas de logique de code, autre que la persistance et l’accès aux données se trouvant dans la base de données. Toute la logique est alors traité un ensemble de règles se trouvant dans le système de base de données. Cela s’appelle des procédures de base de données. Le PLSQL est un bon exemple de langage basé sur ce type d’interactions. Firebase est aussi un bon exemple.
Le problème de ce genre de système est l’évolution dans le temps. Il est bon pour les POC.
Expliquez le MVC.
Le style MVC ou modèle vue controlleur est né de la nécessité de diviser les responsabilités présentes dans la conception d’interface graphique. Ainsi, on divise les responsabilités en 3, le modèle, la vue et le controlleur. Aussi simple que ça! Ce style est revenu en avant-plan avec l’abondance de framework permettant de faire des Single page applications (SPA) facilement [React, Vue, Angular].
Modèle: Le modèle représente les informations ainsi que les méthodes offertes pour manipuler le modèle (changement dans les informations). Lors d’un changement à son état interne, il est alors responsable de notifié la vue de se mettre à jour, c’est à dire, rafraichir le modèle. Le modèle peut être celui qui communique avec la base de données dans le système.
Vue: La vue est responsable de l’affichage du modèle, ainsi que la logique d’intéraction dans le système. C’est avec lui que l’utilisateur interagit. Chaque interaction déclanche alors un nouvel évènement qui sera alors traité par le controlleur.
Contrôleur: Le contrôleur est celui est responsable de la communication entre le modèle et la vue. Il permet de décider quelles actions utilisateurs sont liées à quelles méthodes du modèle. C’est l’aiguilleur entre la vue et le modèle. Il connait alors la logique d’interaction utilisateur. Un bonne façon de le voir, c’est comme un médiateur dans le système. Le contrôleur peut être celui communique avec la base de données dans le système.
Expliquez le modèle en couche données.
Dans les problèmes qui ne nécessite que très peu de protection à une changement provenant de l’espace techno, nous pouvons simplifier les interactions entre les couches en permettant que l’espace de présentation soit directement connecter avec les modèles de l’application. Ainsi, les modèles sont ensuite connectés directement aux systèmes de persistance de l’application. La couche data est responsable alors de la traduction entre le modèle de données dans le code et la structure de persistance. On peut voir la couche data comme la couche de DAO entre les objets du système.
On retrouve surtout des tests larges et mediums.
