Structure différente entre la vue et les données.

Bonjour,

Je suis en train de créer une petite application pour définir des jours de livraison pour des commandes. En base de données, il y a une liste de transporteurs et pour chaque transporteurs une liste de jours de livraison possible. Avec mon application, l'utilisateur doit pouvoir modifier la liste des jours de livraison par transport. J'aimerais pour cela représenter dans une datagrid tous les jours de la semaine et que l'utilisateur puisse cocher les jours de livraison possibles. Le problème est là: en base de donnée, j'ai donc liste de jours de livraison possibles (si un jour n'est pas possible, il ne figure pas dans la table) et côté interface tous les jours sont présentés (si un jour n'est pas possible, il est présent mais décoché).
Pour le moment, j'ai, dans une même classe, mis 2 listes de jours de livraison : une en liaison avec la bdd et une autre en liaison avec l'interface. Je dois évidement compléter la deuxième en me basant sur la première. Mais faire tout ça dans une même classe (les 2 listes plus la logique de synchronisation) me parait un peu sale.
J'ai souvent entendu parler de la méthode de conception MVC et je me demande si je pourrais l'appliquer à mon cas. D'un autre côté c'est peut être inutilement lourd de créer plusieurs classes pour une seule est même entité. Quelqu'un pourrait-il me conseiller ?

Merci

Tu aurais besoin de deux classes :
- ta classe métier qui elle contient la liste des jours de livraisons possibles,
- ta classe de présentation des entités avec ton datagrid, qui contient une référence vers une instance métier qu'elle est censé afficher.

Dès que l'utilisateur coche/décoche un jour dans l'interface :
- un évènement est levé, Checked/Unchecked par exemple si ce sont des checkbox;
- le handler de l'évènement va déterminer quel jour a été modifié et invoquer en conséquence une méthode SelectDay(day)/UnselectDay(day) de ta classe métier qui va se mettre à jour en conséquence.

L'inverse étant aussi vrai : si l'état de ton entité métier change, par exemple le fait de sélectionner un jour en désélectionne un autre, elle va notifier le controler qui va récupérer la liste des jours sélectionnés et modifier en conséquence le control chargé de la présentation.
La notification se fait via l'implémentation du DP observer.
Celui-ci est souvent déjà "implémentés" dans les frameworks graphiques, comme en WPF avec INotifyPropertyChanged.

Ok, mais est-ce vraiment une conception MVC ?
Les 2 classes que tu proposes seraient le modèle et la vue. Mais ne faut-il pas également créer une classe Controleur ?

En fait la deuxième classe fait aussi office de controler ici.
Tu peux aussi extraire ce code de "control" dans une troisième classe.

Ton thread aurait sûrement plus sa place sur le forum conception.

Merci pour ta réponse seriousme.
Est-ce que le modèle doit/peut avoir une méthode GetView() pour obtenir une instance de la view? Sinon, comment obtenir la vue en ayant le modèle?