3. Introduction
L’architecture logicielle décrit d’une manière symbolique et schématique
les différents éléments d’un ou de plusieurs systèmes informatiques, leurs
interrelations et leurs interactions. Contrairement aux spécifications produites par
l’analyse fonctionnelle, le modèle d'architecture, produit lors de la phase de
conception, ne décrit pas ce que doit réaliser un système informatique mais plutôt
comment il doit être conçu de manière à répondre aux spécifications.
L’analyse décrit le « quoi faire » alors que l’architecture décrit le « comment le faire ».
3
5. MVC: Présentation
Le modèle MVC décrit une manière d’architecturer une application
informatique en la décomposant en trois sous-parties :
la partie Modèle .
la partie Vue .
la partie Contrôleur.
5
Ce modèle de conception (design pattern) a été imaginé à la fin des
années 1970 pour le langage Smalltalk afin de bien séparer le code de
l’interface graphique de la logique applicative. Il est utilisé dans de très
nombreux langages : bibliothèques Swing et Model 2 (JSP) de Java, frameworks
PHP, ASP.NET MVC, etc.
6. MVC: Rôles des composants
6
-Encapsule la logique métier
-Encapsule l’accès aux
données.
-S’occupe des interactions
avec l’utilisateur : Saisie et
Validation des données.
-Fait le lien entre l’utilisateur
et le reste de l’application.
8. MVC: Exemple d’une application en MVC
8
Le modèle
• Le modèle est
chargé de la gestion
des données, les
interactions avec la
base de données.
• La classe doit définir
les accesseurs et les
mutateurs.
9. MVC: Exemple d’une application en MVC
9
La vue
• Il est maintenant
possible de créer une ou
plusieurs vues.
• Chaque vue a besoin de
connaître le modèle et
le contrôleur.
10. MVC: Exemple d’une application en MVC
10
Le contrôleur
• Chaque vue est associée
à un unique contrôleur.
• Le contrôleur interprète
les actions de
l’utilisateur et met à
jour le modèle.
11. MVC: Avantages
11
Plusieurs Vues
partagent le
même modèle
Facilité
d’adaptation à
différentes
interfaces
Clarté de la
conception
Facilité
d’expansion
Modularité de la
conception
Facilité de
transformation
en applications
distribuées
Utilisation
possible d’un
modèle multiplat
eforme
14. Exemple2 en MVC
• Nous avons mis la logique de fonctionnement du moteur dans le Modèle et
non dans le Contrôleur.
• Du point de vue de la programmation orientée objet, il est plus logique
d’implémenter le comportement du moteur dans la classe MoteurIndustriel
que dans le Contrôleur.
• Le Contrôleur n’est pas forcément celui qui manipule les données, mais plutôt
celui qui contrôle les échanges de données et la suite logique entre
l’enchaînement de plusieurs interfaces.
14
16. MVP: Présentation
16
• MVP (Model View Presenter)est un modèle dérivé du MVC, qui prend de
l'importance dans le développement d'applications Android.
• MVP est un modèle architectural de l'interface utilisateur conçue pour
faciliter les tests unitaires automatisés et d'améliorer la séparation des
préoccupations dans la logique de présentation.
17. MVP: Rôles des composants
17
-Encapsule la logique métier
-Encapsule l’accès aux
données.
-S’occupe des interactions
avec l’utilisateur : Saisie et
Validation des données.
-Fait le lien entre l’utilisateur
et le reste de l’application.
Définir les
données à
afficher
Récupérer les
données à partir
Afficher des
données
18. Exemple d’une application en MVP
18
• Le Model est la classe
User sous le package
model.
• Cette classe implémente
une interface Parcelable
qui permettra de
transporter un objet de
type User à partir d'une
Intent .
19. Exemple d’une application en MVP
19
L'intêret de Presenter est la
responsabilité de lancer la
connexion et de notifier dans les
cas de succès ou d'échec la View
un écran de connexion dans la vue
suivante
20. Transformer un code existant en MVP
20
Sans MVP:
Le code suivant crée la fenêtre,
contenant une zone de liste pour
afficher les clients disponibles et
une série de zones de texte
montrant des données
supplémentaires liées au client
sélectionné dans la zone de liste.
21. Transformer un code existant en MVP
21
Avec MVP:
Créer une interface qui
servira de contrat de
ce que la Vision soit
capable de faire
22. Transformer un code existant en MVP
22
Avec MVP:
Pour compléter la partie View,
nous devons créer
l'implémentation concrète de
l'interface de visualisation.
23. Transformer un code existant en MVP
23
Avec MVP:
le présentateur parle à la vue en
utilisant son interface au lieu de la
mise en œuvre concrète, pour des
raisons de testabilité.
26. MVVM: Présentation
MVVM signifie Model-View-ViewModel.
• Model, en français « le modèle », correspond aux données. Il s’agit en
général de plusieurs classes qui permettent d’accéder aux données, comme
une classe Client, une classe Commande, etc. Peu importe la façon dont on
remplit ces données (base de données, service web,…), c’est ce modèle qui
est manipulé pour accéder aux données.
• View, en français « la vue », correspond à tout ce qui sera affiché, comme la
page, les boutons, etc. En pratique, il s’agit du fichier .xaml.
26
• View Model, que l’on peut traduire en « modèle de vue », c’est la colle entre
le modèle et la vue. Il s’agit d’une classe qui fournit une abstraction de la
vue. Ce modèle de vue s’appuie sur la puissance du binding pour mettre à
disposition de la vue les données du modèle.
27. MVVM: Présentation
Apparu en 2004, MVVM est originaire de Microsoft et adapté pour le
développement des applications basées sur les technologies Windows
Presentation Foundation (WPF) et Silverlight.
27
Pour rappel, le Binding est un mécanisme qui permet de faire des liaisons
entre des données de manière dynamiques. Ce qui veut dire que si A et B
sont liés, le fait de modifier A va être répercuté sur B et inversement.
28. MVVM: Fonctionnement
28
-Encapsule la logique métier
-Encapsule l’accès aux
données.
-S’occupe des interactions
avec l’utilisateur : Saisie et
Validation des données.
-Fait le lien entre l’utilisateur
et le reste de l’application.
29. MVVM: Exemple d’une application
29
La structure de toute application
travaillant avec l’architecture
MVVM doit contenir le modèle,
la vue et le modèle-vue.
30. MVVM: Exemple d’une application
30
Un modèle simple consistant en
une classe Product avec des
attributs et les méthodes
(Getters et Setters)
31. MVVM: Exemple d’une application
31
Une vue simple pour
afficher les attributs
du modèle Product.
On utilise les
expressions de
balisage pour
indiquer les valeurs
grâce au binding.
32. MVVM: Exemple d’une application
32
Le modèle-vue doit implémenter
l’interface
INotifyPropertyChanged.
Ici on a recours à une classe
customisée l’ObservableObject.
33. MVVM: Avantages
• Le faible couplage entre la Vue et la Vue-Modèle permet de pouvoir modifier
facilement la vue sans avoir d’impact sur la Vue-Modèle (et vice versa).
• Il permet de tester de manière séparée les différents éléments de la solution.
• Il permet une maintenance facilitée des projets.
• Le même code dans les Vue-Modèle et Modèle peut être facilement réutilisé
dans d’autres projets tout en utilisant des vues différentes.
33
35. MVT: Définition
• MVT est un architecture-pattern proche de MVC.
• MVT signifie "Modèle - Vue - Template".
• Le MVT est utilisé par le Framework Django
35
36. MVT: Architecture
• le template l’interface graphique que le client
consulte.
• le modèle décris la base de données.
• la vue contrôle que l’utilisateur peut
consulter.
• Le contrôleur URL Dispatcher.
36
37. MVT: Composants et Fonctionnement
37
-Encapsule la logique métier
-Encapsule l’accès aux
données.
-S’occupe des interactions
avec l’utilisateur : Saisie et
Validation des données.
-Fait le lien entre l’utilisateur
et le reste de l’application.
• le template utilisé est un simple
fichier au format HTML
• Rend les données dans un format
approprié - HTML / XML / etc.
• il sera analysé et exécuté par le
framework, comme s'il s'agissait
d'un fichier avec du code.
• Il sera récupéré par la vue et
envoyé au visiteur
• # template.html
{% extends
'my_project/base.html' %}
<h1>{{ news.title }}</h1>
<div>{{ news.content|safe }}
</div>
38. MVT: Composants et Fonctionnement
38
-Encapsule la logique métier
-Encapsule l’accès aux
données.
-S’occupe des interactions
avec l’utilisateur : Saisie et
Validation des données.
-Fait le lien entre l’utilisateur
et le reste de l’application.
• le modèle s'agit d'une classe où
chaque attribut correspondra à
un champ dans la base de
données.
• définit la structure de données
• prend soin d'interroger la base de
données
# models.py
from django.db import models
from django.utils.translation
import ugettext_lazy as _
class News(models.Model):
title = models.CharField(_('Title'),
max_length=255)
slug = models.SlugField(_('Slug'))
content = models.TextField()
39. MVT: Composants et Fonctionnement
39
-Encapsule la logique métier
-Encapsule l’accès aux
données.
-S’occupe des interactions
avec l’utilisateur : Saisie et
Validation des données.
-Fait le lien entre l’utilisateur
et le reste de l’application.
• la vue est une simple fonction
qui acceptera des paramètres,
par exemple les paramètres
passés en URL.
• La vue ira alors lire dans la base
l'élément correspondant, pour
générer le template pour
affichage à l'internaute.
• définit les données à présenter
• réponse HTTP renvoyée
# views.py
from .models import News
from django.shortcuts import get_object_or_404
def single_news(request, slug):
news =get_object_or_404(News.objects.public(),
slug=slug)
Returnrender_to_response('news/single_news.html',
{'news': news})
40. MVT: Exemple d’une application
40
La structure de toute application
travaillant avec l’architecture MVT
doit contenir le modèle, la vue et
le template.
41. MVT: Exemple d’une application
41
Un Template pour afficher les
attributs du différents modelés
de l’historique de révision.
42. MVT: Exemple d’une application
42
Le modèle d’un class révision qui
s’agit d’une image de la table
dans la base de donnée
43. MVT: Exemple d’une application
43
Le view faire le lien entre le
Template et le model par
récupère les donné du Template
et l’affecter dans le model (user),
44. MVT: Exemples des applications
44
• BitBucket
• DISQUS (serving 400 million people)
• Pinterest
• Instagram
• dPaste
• Mozilla (support.mozill, addons.mozilla)
45. MVT: Avantages
• La partie contrôleur est fournie par le Framework (Django).
• Rapide et facile à apprendre le développement web.
• La séparation des différentes couches d'un programme.
45
46. Conclusion
Règles pour bien choisir entre MVVM, MVP, MVC
46
MVP Pattern
• Utilisation dans des
situations où la liaison par
l’intermédiaire d’un
DataContext n’est pas
possible.
• Windows Forms est un
parfait exemple de cela. Afin
de séparer la vue du
modèle,un présentateur est
nécessaire pour la
communication entre ces
deux.
MVVM Pattern
• Utiliser dans les situations où
la liaison via un DataContext
est possible. Pourquoi? Les
différentes interfaces IView
pour chaque vue sont
supprimés ce qui signifie
moins de code à maintenir.
MVC Pattern
• Utiliser dans des situations
où le lien entre la vue et le
reste du programme n’est pas
toujours disponible.
• C’est le cas pour une API web
qui est séparé des données
envoyées aux navigateurs
clients
La partie Modèle d’une architecture MVC encapsule la logique métier (business logic) ainsi que l’accès aux données.
La partie Vue s’occupe des interactions avec l’utilisateur : présentation, saisie et validation des données.
La partie Contrôleur gère la dynamique de l’application. Elle fait le lien entre l’utilisateur et le reste de l’application.
Le diagramme ci-dessous résume les relations entre les composants d’une architecture MVC.
La demande de l’utilisateur (exemple : requête HTTP) est reçue et interprétée par le Contrôleur.
Celui-ci utilise les services du Modèle afin de préparer les données à afficher.
Ensuite, le Contrôleur fournit ces données à la Vue, qui les présente à l’utilisateur (par exemple sous la forme d’une page HTML).
Pour mieux comprendre le fonctionnement d’un tel système voyons un petit exemple
L’objectif est de créer une interface permettant le contrôle de la température en degrés Celsius ou
Fahrenheit.
Pour mieux comprendre le fonctionnement d’un tel système voyons un petit exemple
L’objectif est de créer une interface permettant le contrôle de la température en degrés Celsius ou
Farenheit.
1) Plusieurs Vues partagent le même modèle – L’implémentation est donc plus simple puisque les Vues utilisent toutes la même interface avec le Modèle.
2) Plus grande facilité d’adaptation à différentes interfaces – Pour ajouter une interface différente, il suffit d’écrire une autre Vue et un Contrôleur puisqu’il ne faut pas modifier le Modèle.
3) Clarté de la conception – En regardant les différentes méthodes du Modèle, il est facile de comprendre comment l’utiliser; l’écriture d’une ou de plusieurs interfaces est donc grandement facilitée. La maintenance est aussi aisée.
4) Modularité de la conception – On peut modifier plus aisément des éléments du système. Le Modèle peut même subir des modifications sans que cela n’affecte le Contrôleur ou la Vue pour autant qu’il se conforme à l’interface définie. De plus, il est possible de développer le système en parallèle si les interfaces du système sont bien définies.
5) Facilité d’expansion – On peut ajouter d’autres Vues et Contrôleurs ou, encore, enrichir le Modèle si on conserve l’interface existante.
6) Facilité de transformation en applications distribuées – Il est facile de transformer une application en applications distribuées (p. ex., passer d’une application graphique standard [en Java avec l’API Swing] à une application Web).
7) Utilisation possible d’un modèle multiplateforme – On peut utiliser un Modèle multiplateforme, et les composantes Vue-Contrôleur peuvent être adaptées à la plateforme. On conserve l’apparence native au système d’exploitation et on conserve la logique du programme commune aux différentes plateformes.
Voici une application simplifiée permettant de surveiller l’état d’un moteur industriel à quatre vitesses. Cette application a été mise au point sans tenir compte du modèle MVC
On modifie le code afin de rendre celui-ci compatible avec l’approche MVC.
Le Modèle est une interface définissant les données à afficher dans l'interface utilisateur.
La Vue est une interface passive qui affiche des données (le modèle).
Le Présentateur agit sur le modèle et la vue. Il récupère les données à partir du modèle pour les afficher dans la vue.
Pour mieux comprendre le fonctionnement d’un tel système voyons un petit exemple
La structure de l'application ressemble à quelque chose comme:
Pour mieux comprendre le fonctionnement d’un tel système voyons un petit exemple
La structure de l'application ressemble à quelque chose comme:
nous allons créer une petite application qui affiche une liste de clients disponibles dans une source de données à l'utilisateur. L'utilisateur pourra sélectionner des clients dans la liste et afficher des détails supplémentaires comme l'âge, le genre et l'adresse e-mail.
Les façons traditionnelles de développer des interfaces utilisateur ont tendance à leur confier toute la responsabilité des données qu'elles gèrent, y compris: l'entrée de l'utilisateur, la validation des données, la gestion des erreurs et l'accès à la base de données.
Ce code brise pratiquement tous les aspects de la bonne conception et, bien qu'il satisfasse visuellement les exigences, il ne peut pas être couvert par des tests unitaires.
La demande des clients devrait:
Afficher tous les clients dans la zone de liste lorsqu'il est chargé.
Afficher les détails du premier client dans la liste lorsqu'il est chargé.
Afficher les détails d'un client et le montrer lorsque l'utilisateur sélectionne un élément dans la zone de liste des clients.
La première chose à faire est de créer le modèle.
Dans ce cas, notre vue contiendra une liste de clients, de sorte que le modèle est en fait la classe Client.
L'étape suivante consiste à créer une interface qui servira de contrat de ce que la Vision soit capable de faire, le présentateur en est conscient, puisqu'il communiquera avec elle pour servir les données de vue et recevoir les entrées.
pour compléter la partie View, nous devons créer l'implémentation concrète de l'interface de visualisation.
Maintenant la personne qui traite l'accès aux données via la classe de dépôt est le présentateur.
Si on exécute l'application à ce stade, nous verrons la boîte de liste des clients remplie, tout comme l'ancienne application, que cette fois-ci, toutes les données arrivent et retournent, la vue se déroule dans le présentateur. le Modèle stocke les données, la vue affiche les données et le présentateur fournit des données.
Maintenant la personne qui traite l'accès aux données via la classe de dépôt est le présentateur.
Si on exécute l'application à ce stade, nous verrons la boîte de liste des clients remplie, tout comme l'ancienne application, que cette fois-ci, toutes les données arrivent et retournent, la vue se déroule dans le présentateur. le Modèle stocke les données, la vue affiche les données et le présentateur fournit des données.
Couplage lâche- Le Présentateur est un intermédiaire entre le code de la Vue et le Modèle. Cela permet à la vue et le modèle d'évoluer indépendamment les uns des autres.
Séparation des préoccupations- Les sections individuelles peuvent être réutilisés, ainsi que développé et mis à jour de façon indépendante.
Plus testable – En isolant chaque composant principal (UI, Présentateur, et modèle), il est plus facile d'écrire des tests unitaires. Cela est particulièrement vrai lorsqu'on utilise le modèle MVP qui ne coopère avec l'affichage à l'aide d'une interface.
Réutilisation du code– En utilisant une séparation des préoccupations / approche responsable de la conception, vous augmenterez la réutilisation du code.
Flexibilité- En isolant la plupart de votre code dans les composants du Présentateur et du Modèle de votre base de code est plus flexible pour changer dans la Vue.
( Le but de MVVM est de faire en sorte que la vue n’effectue aucun traitement, elle ne doit faire qu’afficher les données présentées par le view-model. C’est le view-model qui a en charge de faire les traitements et d’accéder au modèle. )
( Le but de MVVM est de faire en sorte que la vue n’effectue aucun traitement, elle ne doit faire qu’afficher les données présentées par le view-model. C’est le view-model qui a en charge de faire les traitements et d’accéder au modèle. )
MVP
Utilisation dans des situations où la liaison par l’intermédiaire d’un DataContext n’est pas possible.
Windows Forms est un parfait exemple de cela. Afin de séparer la vue du modèle,un présentateur est nécessaire pour la communication entre ces deux.
MVVM
Utiliser dans les situations où la liaison via un DataContext est possible. Pourquoi? Les différentes interfaces IView pour chaque vue sont supprimés ce qui signifie moins de code à maintenir.
MVC
Utiliser dans des situations où le lien entre la vue et le reste du programme n’est pas toujours disponible (et vous ne pouvez pas utiliser efficacement MVVM ou MVP).
C’est le cas pour une API web qui est séparé des données envoyées aux navigateurs clients. ASP.NET MVC de Microsoft est un excellent outil pour la gestion de ces situations et fournit un framework MVC très claire
