Question

J'ai écrit un programme de gestionnaire de tâches en utilisant Java et fait une seule implémentation de l'interface utilisateur pour le moment swing. Le programme dispose de 3 couches pour le moment. Une couche de présentation qui interagit avec la couche de domaine via un contrôleur de cas d'utilisation, et enfin une couche de services techniques utilisés pour la persistance. Il y a plusieurs actions qu'un utilisateur peut prendre à ce point, comme l'ajout des tâches, la modification de l'état d'une tâche, etc ... Le but de mon enregistreur dans ce schéma est de garder une trace de toutes les mesures prises par les utilisateurs. Donc, il y a quelques endroits où je pourrais invoquer l'enregistreur pour écrire une commande. Je ne vais pas faire une exploitation forestière dans la couche de présentation que ce serait une terrible décision de conception et donc je suis parti avec le contrôleur, l'interface de commande (mis en œuvre pour gérer l'exécution de toutes les commandes dans le but de mettre en œuvre undo / fonctions redo ), ou dans les classes de niveau inférieur qui sont en fait manipulés, dire la classe de tâches par exemple.

Je pense que le contrôleur est une option relativement décent pour cela comme il agit comme point de contact entre la couche d'interface utilisateur et le domaine, ainsi toutes les commandes notables passent finalement par le contrôleur rendant pour vérifier facilement que toutes les méthodes importantes sont connectés. Une raison de ne pas le faire dans le contrôleur est qu'il réduira la cohésion, augmenter le couplage et potentiellement conduire à un contrôleur pléthorique.

Les commandes de béton sont un autre emplacement potentiel car ils ont trop toutes les informations nécessaires à l'exploitation forestière. Ce serait à nouveau faire les commandes à devenir moins cohérente et augmente le couplage. De plus, si je ne pas utiliser l'interface de commande pour effectuer une action sur un objet de domaine que je perds mon exploitation forestière.

Enfin cela me conduit à la mise en œuvre de l'enregistreur dans le domaine de niveau inférieur méthodes objets. Ceci est un bon candidat parce que l'exploitation forestière sera toujours se produire si le programme est utilisé et toutes les informations nécessaires sont disponibles. La seule partie négative est que les commandes de l'enregistreur sera peu nichés le domaine de niveau inférieur projet d'objets rendant plus difficile à faire en sorte que toutes les bonnes méthodes sont enregistrés.

J'aimerais obtenir un débat en cours sur ce type de décision et d'apprécier tous vos commentaires.

Était-ce utile?

La solution

Pensez à l'aspect pratique d'abord. L'exploitation forestière est souvent un entretien et questions d'ordre administratif. Chaque couche dans votre conception est un candidat pour l'exploitation forestière, mais pour des raisons quelque peu différentes.

Sans vraiment connaître votre hiérarchie d'objets et le design ...

Allant de domaine à l'interface utilisateur, chaque couche est une abstraction ou une collection de comportement de la couche précédente. Vous devez vous demander des choses comme ce niveau de granularité que vous cherchez? Serait-il utile de voir une consignation d'une commande? Serait-il aussi utile de voir la journalisation pour chaque appel de la couche de domaine associés? Peut-être pas toujours facile à déchiffrer les appels de domaine et l'associer à une commande particulière.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top