Au programme : Ajout des DAOs (Permettra la persistance des données), un diagramme de package pour s'assurer ne pas avoir de dépendances cycliques, Ajout d'un package pour les ihm tout en respectant le MVC.
Ajout de quelques attributs sur les units (room et description, le tout sur l'abstract pour que tout le monde en profite).
Daos :
Les daos permettront de rendre persistantes nos objets domotiques, il est peut être intéressant de pouvoir stocker le statut actuel d'un interrupteur, pratique en cas d'arrêt relance du serveur. Ou encore d'historiser les mesures d'une sonde de températures. Et bien, les DAO (Data Access Object) sont là pour ça.
Attention, chaque Objet Unité possèdera un manager dédié à sa DAO (on passera toujours par un Manager pour sauvegarder des données, les récupérer, ...). Pas d'accès direct par la DAO (permettant ainsi de s'affranchir de ce que fait et comment est organisée la DAO: 1, 2, 3, x DAOs pour une unité, on en sait rien). Donc le manager dédié à chq unité, possèdera une ou plusieurs DAO (interfaces, nommée I<Unité>Dao, ex : IMS13Dao). Ces interfaces seront par la suites implémentées par différentes technologies (tout dépend de quel ORM on utilisera : Hibernate, OJB, DB4O voir jdbc, ou pourquoi pas écriture sur fichier directement). Ces implémentations seront nommées <Unité>Dao<Techno>Impl, ex: MS13DaoHibernateImpl.
Exemple ici, j'ai mis 2 implémentations (Hibernate et Jdbc en bleu) bien évidemment il faudra en choisir une.
Diagramme de packages :
Le diagramme de package permet de visualiser le contenu et l'organisation de notre projet, mais également pas le biais des dépendances de détecter les redondances cycliques au sein du projet. Sur ce diagramme, pas de redondance, en cas de redondance, se reposer la question sur l'organisation des classes dans les packages. Si le problème est insolvable, pensez à la classe Tiers qui manipulerait 2 packages ayant une redondance.
IHM :
Pour appliquer le MVC (Model View Controller) il nous faut donc un organisation en conséquence, j'ai donc créé un package ihm où l'on y retrouve, un package destiné aux actions, ainsi qu'un package destiné aux écrans (JSP) appelé view.Ps : j'ai choisi JSP, mais il existe un tars d'autres technos.
Vous l'aurez donc compris, Actions > Controller, View pour View , mais où est le modèle ? En fait les actions utiliseront les managers qui eux utiliseront les objets (unités, mediators) appelés "models".
Il y a une sort de découplage entre les actions et les managers dits "métiers". Les actions étant spécialisées pour les IHM.
Units :
Petite évolution ajout dans l'AbstractUnit de l'attribut room (désignera là où l'unité se trouve ainsi que la description).
Aucun commentaire:
Enregistrer un commentaire