Discussion :

[PanicKernel]

Bonjour,

J'ai un problème lié à l'implémentation de MVC dans un cas bien particulier (implémentation de MVC en client lourd, pas en Web).

J'ai une vue qui permet de sélectionner un liste d'objets à partir d'une liste de référence. L'utilisateur peut ajouter ou supprimer des objets depuis cette liste en les cochant ou en les décochant.

Ex :

Objet1 [ ]
Objet2 [x]
Objet3 [x]

[OK] [Annuler]

En cliquant sur OK, la liste générée sera {objet2, objet3} et sera assignée à un objet métier parent. Il est possible de modifier cette liste à postériori, dans ce cas des règles se suppression d'un élément de la liste entrent en jeu. Par exemple si à partir de la liste précédente on décoche l'objet2 alors que cela est interdit, un message d'erreur en info-bulle s'affiche et l'objet2 reste coché.

La liste que propose ma vue n'est pas la véritable liste associée à un objet métier, en effet, si cela était le cas, les modifs se feraient direct et donc le bouton annuler serait inopérant.

Comment faire pour implémenter en MVC cette interface alors que la liste est déconnectée de l'objet métier parent écoutable par l'interface ?

Merci.

[hed62]

Comme tout problème de ce type lorsque l'on utilise un MVC : en passant par le controller.

Le controller a accès à l'objet métier. Il peut donc à la fois le modifier, et appeler des méthodes de vérification dessus.

Il a aussi accès à la vue, et sais donc quelles sont les modifications souhaitées par l'utilisateur. A partir de là, il effectue ces modifications, appelle la méthode de vérification, envoie les erreurs+rollback ou valide.

[PanicKernel]

Merci hed 62.

Entre temps j'ai élaboré une solution qui me semble proche de la tienne, à savoir à base d'objet "transactionnel" (un bien grand mot dans mon cas) :
- Ma vue est mappée un véritable objet métier (et non plus une copie);
- les modifications effectuées par l'utilisateur sont relayées vers le controleur ;
- le controleur appelle un service pour réaliser l'opération ;
- le service effectue les vérifications (une exception est levée si une règle de gestion est violée), si les vérifs sont OK, une transaction débute sur l'om et il est modifié ;
- [cas d'erreur], le controleur demande à la vue d'afficher le message d'erreur ;
- [modification effectuée] la vue est mise à jour par l'om ;
- l'utilisateur valide l'écran par OK -> le service commite l'om ;
- l'utilisateur annule -> le service fait un rollback sur l'om.

Voilà, dites moi ce que vous en pensez.

[hed62]

Ca me semble tout à fait correct.

[PanicKernel]

Merci, j'espère que ça va bien marcher alors

[behess]

Bonjour,

j'aurais quelques questions sur cette conception.

Je vais les poser sous forme affirmative, merci de me contredire et de m'expliquer ce que je n'aurais pas compris.

1. Dans ton exposé "om" désigne un objet modèle, c'est bien ça ?
2. Ce serait une sorte de tampon entre l'application et la base de données ?
3. Le commit et le rollback se font sur le tampon et pas sur la base de données ?
4. Y-a-t-il possibilité de "concurrence" sur les données ?
5. Une modification des données "en base" par un autre utilisateur aura quelle conséquence sur l'objet modèle ? Comment gère-tu ce cas ?

[hed62]

Bonjour,

1. Dans ton exposé "om" désigne un objet modèle, c'est bien ça ? Oui
2. Ce serait une sorte de tampon entre l'application et la base de données ? Oui, il s'agit de la couche Modèle du MVC
3. Le commit et le rollback se font sur le tampon et pas sur la base de données ? Oui, la couche Métier gère les accès base pour découpler la technique de la base des couches supérieures
4. Y-a-t-il possibilité de "concurrence" sur les données ? Tout dépend de l'implémentation et des différents lock mis en place
5. Une modification des données "en base" par un autre utilisateur aura quelle conséquence sur l'objet modèle ? Comment gère-tu ce cas ? Même réponse.