[WPF][Archi] Peut on combiner 3-tiers et MVVM, aperçu de ma solution.

Version imprimable

05/05/2011, 17h27
takinelinfo

[WPF][Archi] Peut on combiner 3-tiers et MVVM, aperçu de ma solution.

Bonjour à tous,

Débutant en C#/WPF, je me pose quelques questions sur l'architecture de mon application.
Je voudrais mixer une Archi "3-tiers" et utiliser la méthodologie (ou design) MVVM.
Je voudrais donc savoir si c'est compatible et si ce n'est génant (ou déconseillé).

Vouici un aperçu de ma solution ainsi que des références.
http://www.developpez.net/forums/att...1&d=1304609195
Par avance, merci.
05/05/2011, 17h39
ostenhard

Bonjour,

Non ce n'est pas gênant et heureusement par contre il y a une erreur de langage entre ton schéma et le terme tiers.

Ton schéma montre des couches : ici du 3 couches + 1 (transverse = Tools + Entités) et non 3-tiers.

Sinon j'ajoute un point de réflexion qui me dérange sur cette utilisation du MVVM qui est faite assez souvent (par rapport au MVP que j'ai pas mal utilisé).
Dans le cas du MVP, le M(odel) n'était pas dans la couche GUI et car le but était de séparer la représentation des données (Model) dans la vue (en gros les données manipulables par les vues) et la présentation des données faite les V(ues). Le model était alors dans la couche Controller (entre GUI et BLL) ce qui présente l'énorme avantage d'avoir une représentation des données modifiables indépendantes des vues. Ce qui permet notamment de ne pas être lié à la techno de présentation...

Donc qu'en est-il pour le MVVM ? Pour moi c'est absurde d'utiliser le MVVM comme présenté ici.

Désolé de m'être étendu !!!
05/05/2011, 18h28
DonQuiche

Bonjour Ostenhard.

Je ne suis pas certain de ce que tu veux dire. MVVM = model, viewmodel, view. Ici, la vue (XAML + un peu C#) et le viewmodel (tiers - voire couche - présentant des objets directement bindables par l'UI, des commandes, etc) sont rangés dans l'UI, la BLL fait office de model. Le fait que le VM appartienne à l'UI est pour moi logique car les objets de celles-ci sont intimement liés à l'UI : si tu as besoin d'une combobox dans la vue, tu crées dans le VM une propriété offrant une liste de chaînes ou objets à afficher dans la combobox. Si tu veux changer ta vue en profondeur, tu dois changer au moins partiellement la VM, la BLL restant bien entendu intacte (en théorie du moins).

Tu penses donc qu'il faudrait ajouter une couche données intermédiaire entre la BLL et le viewmodel, alors que le viewmodel a déjà pour tâcher de créer des objets intermédiaires servant de représentations adaptées à la vue des objets métiers ? Pourquoi ce niveau d'indirection supplémentaire ? En effet, de deux choses l'une : soit tu as des objets BLL directement manipulables par la vue, soit quand ils ne le sont pas tu vas de toute façon devoir créer des représentations dans la VM.

Il faut comprendre qu'une VM contient plusieurs objets de tailles diverses. SI on imagine une appli commerciale, on aura par exemple :
* Un ListeClientsVM qui sera intimement lié à la vue car les données et commandes qu'il exposera seront directement dépendants des infos et actions présentées par la vue.
* Un ClientVM qui offre des propriétés Nom, Prénom, LigneAdresse1, etc. Si tu changes ta vue, il y a peu de chances que cet objet doive changer car il peut être utilisé aussi bien pour un simple aperçu, une vue détaillée ou une vue avec édition. Au pire auras-tu besoin d'ajouter ou supprimer une ou deux propriétés (par exemple, une représentation textuelle raccourcie) mais, dans l'essentiel, cet objet bougera peu.
06/05/2011, 09h22
takinelinfo

Ci je résume bien:
@ostenhard: N'est pas d'accord avec la structure que je présente.
@DonQuiche: Plutôt d'accord.

Comme je l'ai dit, je débute en C#. J'utilise le 3 couches (GUI/BLL/DAL) et j'ai regardé vite fait le MVVM hier.
Afin d'être sûr d'avoir compris, j'ai réalisé cette maquette pour voir si j'avais bien serné les choses.

Hors j'ai un petit doute, ne devrait t'il pas y avoir une sous couche model dans le projet GUI?Ceci afin de rajouter des entités qui hérite de mes entités classiques mais qui implémente INotifyPropertyChanged?
06/05/2011, 10h04
Nathanael Marchand

Citation:

Envoyé par takinelinfo

Ci je résume bien:
@ostenhard: N'est pas d'accord avec la structure que je présente.

Il est pas d'accord car quand on dit N-tiers, c'est que les N couches sont séparées physiquement.

Citation:

Envoyé par takinelinfo

Hors j'ai un petit doute, ne devrait t'il pas y avoir une sous couche model dans le projet GUI?Ceci afin de rajouter des entités qui hérite de mes entités classiques mais qui implémente INotifyPropertyChanged?

En fait, ca y est implicitement, ce sont les proxy générés par Visual Studio pour accéder à ta BLL via WCF
06/05/2011, 10h26
ostenhard

Euh... ok, je vois mieux la philosophie !
Il n'empêche que je trouve que le ViewModel pour tout ce qu'on y met est très (trop ?) lié à la techno de présentation. Plus il y aura de choses dedans, plus l'effort de test sera important et non automatisable si trop lié à la techno de présentation, mon interrogation est là !
06/05/2011, 10h33
Nathanael Marchand

Citation:

Envoyé par ostenhard

Plus il y aura de choses dedans, plus l'effort de test sera important et non automatisable si trop lié à la techno de présentation, mon interrogation est là !

C'est quand même assez rare ce cas la. Normalement, y'a que des Collections, des booléens, des Strings et des commandes... C'est à peu près multi-techno non?
06/05/2011, 12h24
DonQuiche

Citation:

Envoyé par ostenhard

Euh... ok, je vois mieux la philosophie !
Il n'empêche que je trouve que le ViewModel pour tout ce qu'on y met est très (trop ?) lié à la techno de présentation. Plus il y aura de choses dedans, plus l'effort de test sera important et non automatisable si trop lié à la techno de présentation, mon interrogation est là !

Tu marques en effet un point avec les tests. Mais, en pratique, penses-tu que la situation soit très différente par rapport à ce que tu fais ? Après tout, le "surmodèle" que tu introduisais entre la BLL et le contrôleur, on le retrouve contenu dans la VM, c'est simplement qu'on ne systématise pas la création d'objets intermédiaires puisqu'on s'autorise à parfois utiliser directement les objets métiers. Quant à la partie de la VM qui, elle, est fortement liée aux besoins de la vue, elle change tout autant que ton contrôleur.

@takinelinfo
Pour revenir sur le problème qui a été pointé dans le diagramme de l'OP... Je ne suis pas sûr de comprendre. Selon moi, la différence entre un tiers et une couche est une question d'herméticité : une couche ne communique qu'avec les couches voisines alors qu'un tiers a des contraintes moins rigides (ex : dans MVC, V peut interroger C et M, C peut interroger V et M). Jusque là je crois que c'est à peu près admis par tout le monde et que c'est peut-être ce à quoi Ostenhard se réfère. Seul problème... quand on parle d'architecture 3-tiers, on se réfère à une architecture en 3 couches, donc pas de problème ici.

Ou alors, peut être Ostenhard se référait-il simplement à la représentation des douches transversales, qu'on représente plutôt perpendiculaires aux autres couches (un rectangle étiré en hauteur sur la gauche ou la droite des trois couches principales ici).
06/05/2011, 13h57
takinelinfo

http://www.developpez.net/forums/att...1&d=1304683019
Pour être sur que l'on parle de la même chose, voici un exemple de solution.
Est ce que cela vous semble correct?

Principe pour l'insertion:
GUI.View bindée sur sur GUI.ViewModel, GUI.ViewModel possède un Model.UserEntityView
GUI.ViewModel convertit l'objet GUI.Model.UserEntityView en EL.UserEntity appelle BLL.Business, par exemple bool AddUser(UserEntity);
BLL.Business invoque DAL.UserManager.Add(UserEntity);

Principe pour l'affichage
GUI.View bindée sur sur GUI.ViewModel, GUI.ViewModel possède un Model.UserEntityView
GUI.ViewModel appelle BLL.Business, par exemple UserEntity GetUser(int);
GUI.ViewModel reçoit un EL.UserEntity et le convertit en GUI.Model.UserEntityView afin d'ajouter par exemple le support de INotifyPropertyChanged.
View étant biendé au ViewModel => Ok

Utilité de:
-> UserEntity, avoir une entité simple et indépendante de toute techno. Donc toutes les entités EDMX sont convertit sur ce principe par la DAL.
-> UserEntityView, rajouter le support de INotifyPropertyChanged pour la partie Graphique.
06/05/2011, 14h02
Nathanael Marchand

Pas sur de l'utilité du Model dans GUI mais sinon oui c'est pas mal :)

Mais à ce moment là, comment tu implémentes INotifyPropertyChanged ?
Ce sont les entités transverse?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class UserEntity : INotifyPropertyChanged 
    {
        private int _Id;
        public int Id {
            get { return _Id; }
            set { _Id = value; OnPropertyChanged("Id"); } 
        }
 
        private int _Lastname;
        public int Lastname
        {
            get { return _Lastname; }
            set { _Lastname = value; OnPropertyChanged("Lastname");}
        }
 
        public event PropertyChangedEventHandler PropertyChanged;
        protected virtual void OnPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }

Ce qui m'embète si c'est ça, c'est que je crois que si tu fais un service WCF, par exemple pour coupler ton appli à du Silverlight, tu ne peux pas transférer tes entités car celles-ci ne sont pas compatible du fais de INotifyPropertyChanged. J'ai bien dit il me semble, je n'ai aucune certitude.

06/05/2011, 14h49
ostenhard
Citation:

Pas sur de l'utilité du Model dans GUI mais sinon oui c'est pas mal

C'est même mal non ? cf http://japf.developpez.com/tutoriels...estables/#LV-B

Sinon un point vraiment à part, le nommage de tes projets est bizarre :
- Pourquoi préfixer tous les projets par WPF. ? Si le WPF veut dire Windows Presentation Framework biensur !
06/05/2011, 15h06
takinelinfo

Le nommage c'était juste comme ça... :cry:
Normalement je fais NomDeMaBoite.NomProjet.NomDeCouche

Et je n'aurai pas du nommer le dossier Model dans mon projet GUI, ça porte à confusion, plutôt ViewEntity.
Le modèle de MVVM c'est en fait BLL+DAL dans mon cas!
06/05/2011, 15h36
Nathanael Marchand

Mais c'est quoi le ViewEntity enfait?
06/05/2011, 15h39
DonQuiche

Pour l'organisation de ta solution, personnellement je te décommande d'avoir un dossier "view", un dossier "viewmodel", etc. En effet, en pratique, une vue se découpe en plusieurs sous-vues : pour l'explorateur windows, tu aurais plusieurs sous-vues possibles pour le panel de gauche, et plusieurs autres pour le panel de droite (pour windows forms on aurait utilisé des contrôles persos, ici on utilise des sous-vues). Et chaque sous-vue peut avoir plusieurs objets relevant du VM : des convertisseurs, etc. Au final je trouve plus simple d'avoir tous les objets V et VM associés à une même vue dans un même dossier.

Sinon, non, pas de INotifyPropertyChanged ou ObservableCollection dans la BLL. En effet, cette interface et cet objet ont pour but de permettre aux objets d'être bindés à la vue. Or, si un objet doit être bindé à la vue, alors il doit appartenir au VM, pas au modèle. Même si je comprends qu'il est tentant pour ces objets qui reflètent des objets métier d'appeler ça modèle (j'utilise le terme de "primitives du VM" perso). Mais le modèle, c'est la BLL.

Enfin, pour revenir sur l'organisation des dossiers de la solution, dans la mesure où tu auras des primitives partagées entre les vues, si tu adoptes un dossier par vue, il te faudra une sorte de dossier "commonVM" ou "primitives".

@Nathanael Marchand
Mais c'est quoi le ViewEntity enfait?

Baie c'est l'équivalent de mon entité, mais avec le support de INotifyPropertyChanged et OBservableCollection.
Par exemple:
UserEntity

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
    public class UserEntity
    {
        public int Id { get; set; }
        public string Lastname { get; set; }
        public string Firstname { get; set; }
 
        public UserEntity()
        {
        }
 
        public UserEntity(int id)
        {
            Id = id;
        }
 
        public UserEntity(int id, string lastname, string firstname)
        {
            Id = id;
            Lastname = lastname;
            Firstname = firstname;
        }
    }

[B]UserEntityPrimitive [/B

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
    public class UserEntityPrimitive : INotifyPropertyChanged
    {
        private long _id;
        public long Id
        {
            get { return _id; }
            set{
                _id = value;
                RaisePropertyChanged("Id");
            }
        }
 
        private string _lastname;
        public string Lastname
        {
            get { return _lastname; }
            set {
                _lastname = value;
                RaisePropertyChanged("Lastname");
            }
        }
 
        private string _firstname;
        public string Firstname
        {
            get { return _firstname; }
            set {
                _firstname = value;
                RaisePropertyChanged("Firstname");
            }
        }
 
        public UserEntityPrimitive()
        {
        }
 
        public UserEntityPrimitive(int id)
        {
            Id = id;
        }
 
        public UserEntityPrimitive(int id, string lastname, string firstname)
        {
            Id = id;
            Lastname = lastname;
            Firstname = firstname;
        }
 
        public event PropertyChangedEventHandler PropertyChanged;
        public void RaisePropertyChanged(string element)
        {
            if(PropertyChanged!=null && !string.IsNullOrEmpty(element))
                PropertyChanged(this, new PropertyChangedEventArgs(element));
        }
    }

27/09/2011, 09h37
rvzip64

Je me pose exactement la même question au sujet de "UserEntity" et "UserEntityPrimitive".

Est ce que c'est la bonne architecture à mettre en place ?