Discussion :

[altea35]

Bonjour,

Je développe un logiciel en java avec swing en utilisant l'architecure MVC.
Je vais illustrer mon probleme autour du scénario "Edition d'un fournisseur"

J'ai donc créé les classes correspondantes au modele, qui ne font pour le moment que stocker les données :

(extrait de la classe model Provider :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public class Provider implements PropertyChangeObservable{
 
	public enum Property {NAME, ADDRESS, PHONE, ....
	public enum SortableProperty {NAME, ADDRESS, ....
 
	private String name;
	private String address;
	private String phone;
	private String fax;
	private String email;
	private String comment;
 
       //getters et setters....
}

- la vue sous forme de boite de dialogue representée par la classe ProviderDialogView qui ne se contente que d'afficher les données du modele
- et la classe controller ProviderController associée a cette vue qui recupere les donnees de la vue et les affecte au modele lors de l'apui de l'utilisateur sur le bouton OK de la boite de dialogue.

Jusque la tout va bien. Cependant je voudrai ajouter une logique de validation des donnees. Par exemple que l'email entré soit bien au format mail@toto.com.
Apres m'etre renseigné longuement sur le sujet pour savoir dans quelle couche MVC cette logique doit etre implementée, j'en ai conclu que cela devait se situer dans la couche du modele.

Je voudrais savoir comment vous faites pour implementer cette validation des données dans le modele, et comment faire remonter les erreurs vers la vue affichée par le controller en temps réelle (un message est affiché dès que l'utilisateur entre une donnée invalide, a la maniere des boites de dialogue sur Eclipse).

En gros comment gérez vous le validation des données en respectant le modele MVC ?

[bigbear19]

Salut,

Je ne suis pas un spécialiste du modèle MVC (j'ai juste fait une ou deux petites applis...) mais a priori je dirais qu'il n'y a pas de solution unique.

Par exemple, certaines librairies graphiques fournissent des composants qui contrôlent eux-même les données (pour quelques types seulement) avant de déclencher les actions associées (j'ai vu ça sur un projet en GWT).

Sinon, en ce qui concerne la remontée de l'erreur, les exceptions me semblent bien appropriées. Le contrôleur catch les exceptions provenant du modèle et peux ensuite diriger l'utilisateur vers une page d'erreur par exemple.

[Ivelios]

Si tu en as le courage, tu peux essayer de répertorier toutes les erreurs et les traiter avec JUnit
Je le repete...si tu as le courage

[virulent]

Bonjour à tous,

Je vais essayer de répondre à tes questions altea 35.

Tout d'abord:

Je voudrais savoir comment vous faites pour implementer cette validation des données dans le modele

Dans le modèle MVC, le modèle ne doit pas faire autre chose que de s'occuper de stocker des données.C'est comme un Bean(mais de modèle.....).

Tous les traitements et les contrôles dans un modèle MVC s'effectuent dans le contrôleur ou via le Contrôleur.

Quand ton user appuie sur le bouton 'OK' , le Contrôleur récupère les données de la vue avant de les passer à ton modèle.
Il faut effectuer tes tests avant le passage au modèle. Il faut que ce que le Contrôleur passe au modèle ait été vérifié.

A mon avis deux solutions:

Soit tu créés une classe du genre ProviderValidation qui te permets de valider toutes les données de ton modèle.

Soit tu le fais dans ton Contrôleur, si celui ci est spécifique à ton type de modèle.

En tous cas ne jamais faire de traitements dans le Modèle....

Voila , voila...

======
JAVA bien , merci

[zorm]

répertorier toutes les erreurs et les traiter avec JUnit

J'aimerais bien que tu m'expliques comment tu effectuerais ce traitement avec JUnit? Pour rappel, JUnit est un framework de test unitaire, c'est à dire qu'il permet de valider le bon fonctionnement des méthodes d'une classe par des systèmes d'assertion (du genre, est ce bien vrai que lorsque je passe 2 et 2 en entrée d'une méthode d'addition, j'obtiens bien 4 en sortie).

Bref, pour rejoindre bigbear19 je ne ferais pas les tests au niveau métier, j'effectuerai plutot ça (dans ton cas) dans le controlleur avant de lancer le traitement. C'est à dire que la partie métier ne reçoit que des données déjà validées pour n'avoir qu'à s'occuper de la partie traitement purement fonctionnelle.

Après, pour les vérications, j'aurais tendance à me faire des classes utilitaires (style "singleton" si tu connais le pattern).
Par exemple, tu peux imaginer une classe StringUtils qui ne ferait que des vérifications où pré traitement sur des chaines de caracteres:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public final class StringUtils {
 
    private StringUtils() {
 
    }
 
    public static boolean isEmpty(String pChaine) {
 
        if (pChaine == null || pChaine.equals(Constantes.CHAINE_VIDE)) {
            return true;
        }
        return false;
    }
}

qui s'utiliserait ensuite de la manière suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
   StringUtils.isEmpty(ton_parametre);
   ...

[saziley]

Je suis d'accord sur ce qui vient d'etre dis un peu plus haut, par contre je ne vois pas l'utilité de créer une telle classe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public final class StringUtils {
 
    private StringUtils() {
 
    }
 
    public static boolean isEmpty(String pChaine) {
 
        if (pChaine == null || pChaine.equals(Constantes.CHAINE_VIDE)) {
            return true;
        }
        return false;
    }
}

Il existe pas mal de méthodes manipulant les Strings, il ne faut pas réinventer la roue.
Implémenter une classe de validation est une chose, redéfinir des méthodes déjà existantes en est une autre et cela fait perdre du temps et de l'argent...

++


---

[zorm]

Il existe pas mal de méthodes manipulant les Strings, il ne faut pas réinventer la roue.
Implémenter une classe de validation est une chose, redéfinir des méthodes déjà existantes en est une autre et cela fait perdre du temps et de l'argent...
++

Il s'agissait dans mon cas d'un exemple, d'où le:

Par exemple, tu peux imaginer ...

Bien, après c'est sur que les gouts et les couleurs. Mais je trouve que ton raisonnement est tout aussi discutable. Je ne suis pas persuadé que cela entraine de la perte de temps (et d'argent encore moins) et bien au contraire, car:

• Recourir à des classes utilitaires est très pratique. Elles sont rapidement identifiables, fortement réutilisables dans le projet mais aussi dans de futur projet et facilement testables...

Je n'ai jamais dit qu'il fallait recourir à une réécriture de méthodes existantes. En java, il existe des tas de librairies qui contiennent effectivement ce genre de méthode.

• Mais maintenant, rechercher une librairie contenant ce que tu veux prend du temps, elle n'est pas forcement complete par rapport à tes besoins donc recherche à nouveau...
• De plus, quand tu récupères des méthodes de librairies, tu ne maitrises pas l'implémentation, elle peut très bien contenir des bugs, avec une complexité élevée... Du coup, si tu veux intervenir dessus, tu dois récupérer les sources (si elles sont disponibles), identifier les problèmes... Ca prend du temps.
• Même pour l'argument argent en lui même. Récupérer des librairies externes est couteux car on peut imaginer que tu veuilles utiliser 2 ou 3 méthodes de la classe StringUtils disponible dans le jar Spring core, par exemple. Alors en faisant ça, tu récupères un jar qui fait des centaines de KOctets, sans compter les dépendances à récupérer (qui pèse aussi), le temps passé à tout mettre en place, tout ça pour quelques méthodes... A faire ça, tu te retrouves avec des applis qui se comptent en Mo, voir Go. C'est couteux je te l'assure (je parlerais même pas des prefs de l'appli).

Bref, tout ça pour dire que la méthode que j'ai écris et qui n'est pas compliquée (j'aurais très bien pu récupérer ailleurs, là n'est pas le problème) m'a pris 5 minutes en prenant mon temps pour l'écrire, ne pèse que quelques octets au final dans le futur binaire et est totalement en accord avec mon besoin immédiat, pouvant être utilisée partout dans l'appli dès que besoin...

[Antoine_935]

Nous nous servons du même type de classe dans le cours de POO. C'est très utile, et même si au début c'est déroutant, ça devient vite agréable.

Par contre nous utilisons des méthodes qui lancent une exception si le test ne passe pas. C'est adapté dans la plupart des cas. Et comme les IllegalArgumentException et ses enfants ne demandent pas de les rajouter dans la close throws, ça reste transparent tout en assurant un bon fonctionnement.

[Antoine_935]

Désolé pour le double post, mais l'autre date de quelques heures déjà, et l'ordre d'idée est tout à fait séparé.

Puisque nous sommes en MVC, pourquoi ne pas simplement créer une "pseudo vue" (comprendre "non graphique"), qui retournera par appel de fonction si oui ou non les données du modèles sont valides ?

Finalement, c'est aussi une vue sur le modèle...

Par contre ça implique que toutes les infos soient dans un modèle.

[professeur shadoko]

je ne sais pas si c'est ce que Antoine veut dire , mais, à mon humble avis, M, V et C sont des rôles et il ne faut pas être trop dogmatique dans leur découpage...
Exemple: pour des vérifications élémentaires de saisie je les fais faire par la vue et, dans certains cas, le controleur ou le modèle "donnent" à la vue des codes qui vont faire ces contrôles (le controleur ne récupérant que des données métier complexes bien formées une fois que la saisie est ok). On pourrait aussi considérer que à l'intérieur d'une "vue" on peut retrouver la sainte trinité MVC à un autre niveau ....

[virulent]

pour des vérifications élémentaires de saisie je les fais faire par la vue

En effet , je partage la vision de professeur shadoko. Il peut y avoir des contrôles de base dans les vues. Et heureusement d'ailleurs, car dans un développement WEB, javascript est essentiel à ce niveau là. Avant d'envoyer un formulaire au serveur, il faut bien faire quelques vérifications pour ne pas multiplier les appels.

Ce qui est certain par contre c'est que le modèle ne doit pas avoir des méthodes de contrôle. ( enfin ne doit pas....rien n'empêche de le faire mais bon MVC n'a plus lieu d'être)......

Il faut voir MVC plus comme une bonne pratique pour le développement que comme une architecture à proprement parler.(même si s'en est une...).

Le MVC tend à simplifier les interactions entre les couches afin que la modification de l'une ait le moins( aucune normalement....) de répercutions sur les deux autres....


====
JAVA bien merci