Où les ActionListeners devraient-ils résider dans une architecture MVC ?

MVC et interface graphique : à quelle place les ActionListeners appartiennent-ils selon le modèle MVC ?

Contexte :

Comme vous l'avez mentionné, cette question concerne le placement des ActionListeners dans le Le modèle architectural Model-View-Controller (MVC), utilisé pour créer des interfaces graphiques en Java, ne suit pas strictement MVC.

Placement des ActionListeners :

1. Responsabilité de la vue :

Techniquement, la vue devrait être responsable de la maintenance des ActionListeners attachés aux contrôles de l'interface utilisateur. La vue doit ensuite informer le contrôleur des actions entreprises. De cette façon, le contrôleur est isolé des composants de l'interface utilisateur et peut fonctionner avec n'importe quelle vue implémentée.

2. Écouteur de vue dédié :

Au lieu d'attacher des ActionListeners directement au contrôle de l'interface utilisateur, vous pouvez également créer une vue dédiée. Auditeur. Cet écouteur décrira les actions que la vue peut produire, par exemple :

public interface MainViewListener {
    void didPerformClose(MainView mainView);
}

Le contrôleur s'abonnerait alors à la vue via cet écouteur, et la vue appellerait didPerformClose lorsque le bouton de fermeture est enfoncé.

Gestion de la communication inter-couches :

Idéalement, les couches dans une architecture MVC doit communiquer via des interfaces. Cela établit un couplage lâche, permettant aux couches d'être remplacées indépendamment. Vous souhaitez minimiser la conscience que chaque couche a des autres.

Exemple mis à jour :

Exemple de vue de connexion avec couplage lâche :

Considérez un exemple de connexion, où le CredentialsView et LoginView ont des responsabilités spécifiques :

CredentialsView :

Rassemble les informations d'identification (nom d'utilisateur et mot de passe)
• Avertit le contrôleur lorsque les informations d'identification changent
• Désactive/active les champs pendant authentification

LoginView :

Gère le CredentialsView
• Notifie le contrôleur des demandes/annulations d'authentification
• Ignore la vue sur la réussite/l'échec authentification

En utilisant des interfaces de communication, les deux vues et le contrôleur peuvent être facilement remplacés ou mis à jour sans casser le système.

Placement ActionListeners :

Dans l'exemple mis à jour, les ActionListeners pour les boutons d'authentification et d'annulation sont toujours dans LoginView. Cependant, LoginView agit. en tant que contrôleur pour CredentialsView et vue pour LoginViewController. Cette approche simplifie la logique tout en maintenant une séparation claire des responsabilités.

En conclusion :

• Les ActionListeners doivent être maintenus par la vue, informant le contrôleur des actions.
• La communication entre les couches doit se faire via des interfaces pour favoriser un couplage lâche.
• Conception minutieuse des responsabilités de la vue, responsabilités du contrôleur et la communication inter-couches aide à maintenir l'intégrité du modèle MVC.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!