Description de l'architecture
Vue d'ensemble
L'architecture de notre application est basée sur l'utilisation d'un modèle et d'une vue seulement.
Elle est conçue pour répondre aux besoins des joueurs du jeu Minecraft. Cette solution est composée de 4 projets dont 2 principaux : le Modèle et les Vues (aussi la console et les tests unitaires).
Le Modèle représente l'ensemble des classes de notre application : nous avons une classe User (utilisateur), une classe Conseil, et une classe Monstre. Nous utilisons principalement ces classes dans notre applications par l'intermédiaire du projet Persistance.
Aussi, la classe Conseil est utilisée dans Monstre (Liste de conseil pour chaque monstre), et la classe Monstre dans User (Liste de monstres déjà vus pour tel utilisateur).
La Persistance possède de nombreuses classes : les loaders (XML, JSON, Stub...) qui permettent de charger et de sauvegarder les Users et les Monstres. Elles possèdent le code des différentes fonctions. Nous avons aussi 2 Manager, qui nous permettent de d'appeler par l'intermédiaire de 2 interfaces les fonctions contenues dans les loaders. (pour plus d'informations, voir la section suivante)
Nous avons aussi différentes fonctions de recherche dans les Manager, qui sont ensuite utilisées dans les Vues et leur code-behind.
Les Vues sont donc les différentes pages de notre applications. Elles interagissent avec le modèle pour récupérer les données nécessaires à l'affichage, mais aussi pour réagir et répondre aux actions de l'utilisateur. A noter que nous déclarons les 2 Managers avec leur type de loader dans le code-behind de App : cela nous permet d'y accéder dans les autres vues du projet. Nous avons différentes pages ayant des fonctionnalités complètement différentes : la page d'accueil permet à l'utilisateur de sélectionner la méthode de connexion, tandis que la page principale nous permet de très nombreuses fonctionnalités : des interactions avec les bases de données, la recherche de Monstre dans la bd, mais aussi le filtrage de Monstres, l'ajout, la modification, la suppression de Conseils...
Nous utilisons le Binding sur nos Managers pour afficher les informations nécessaires dans les vues, en ayant implémenté INotifyPropertyChanged dans les classes que l'on veux "binder".
Patrons de conception
Nous avons utilisé 2 patrons de conception :
La Strategy
Ce patron nous permet d'utiliser différentes classes de Loader, directement dans le constructeur de Manager. Nous déclarons en fait une interface communes à tous les Loaders, de façon à utiliser celui de notre choix :
Nous faisons une injections de dépendance dans le constructeur de Manager, de type I.....Manager() (nous avons 2 Manager, donc 2 interfaces aussi).
La façade
Nous avons aussi utilisé la façade, notamment dans l'utilisation des Managers : en effet, les interfaces I.....Manager() nous permettent de simplifier l'accès aux différentes méthodes de chargement et de sauvegarde des Loaders.
N.B : Les dépendances entre les différents projets sont expliquées dans la vue d'ensemble de l'architecture.