IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Presentation Foundation Discussion :

Architecture d'une application modulaire


Sujet :

Windows Presentation Foundation

  1. #1
    Membre éclairé Avatar de chamamo
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    588
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 588
    Points : 735
    Points
    735
    Par défaut Architecture d'une application modulaire
    Bonjour,

    je vous expose brièvement mon problème, je suis entrain de concevoir une application avec plusieurs modules métiers. chaque module métier contient plusieurs formulaires.

    devrais-je mettre un assembly par module métier ou plutôt un assembly pour chaque niveau (Views, viewModels, services, models..)?

    Je compte passer exclusivement par des interfaces pour rendre mon application testable (IView View, IViewModel ViewModel, IService Service...), devrais-je mettre l'interface avec son implémentation dans le même assembly? ou plutôt un assembly que pour les interfaces?

    Je compte m'orienter vers Prism pour la modularité (je ne sais si c'est la meilleure façon de le faire), d’après ce que je viens de décrire, est ce qu'un module métier correspond à un module Prism?

    C'est plutôt des questions d'architecture et de modélisation que je suis entrain de me poser avant de me lancer

    Merci d'avance.

  2. #2
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 742
    Points
    9 742
    Billets dans le blog
    3
    Par défaut
    Déjà pas évident de te répondre, car il faudrait avoir beaucoup plus d'infos sur le projet. Donc je vais te donner mon avis perso par rapport à ce que j'ai capté.

    Citation Envoyé par chamamo Voir le message
    je vous expose brièvement mon problème, je suis entrain de concevoir une application avec plusieurs modules métiers. chaque module métier contient plusieurs formulaires.
    Jusque là, ça reste classique

    Citation Envoyé par chamamo Voir le message
    devrais-je mettre un assembly par module métier ou plutôt un assembly pour chaque niveau (Views, viewModels, services, models..)?
    Je mettrais un assembly par module. Les livraisons en seront simplifiées, puisque tu pourras livrer chaque module indépendamment les uns des autres. Par exemple voici les assemblys que je mettrais :
    - Common
    --- Interfaces
    --- Security
    --- Controls
    --- Tools
    --- ...
    - ModuleA
    --- Views
    --- ViewModels
    --- Models
    - ModuleB
    --- Views
    --- ViewModels
    --- Models
    - ModuleC
    --- Views
    --- ViewModels
    --- Models

    Chacun des projets contenant des répertoires afin de bien compartimenter les fichiers CS. J'ajouterai que si tu as une seule et même base de données, tu peux également rajouter un projet pour la DAL, de manière à factoriser un maximum. Si chaque module utilise une DB différente, alors chaque module devra avoir sa propre DAL.

    Chacun des modules s'appuie sur le projet Common. En revanche, aucun module ne doit avoir de lien avec un autre module, sauf bien sûr si un des modules est construit par-dessus l'autre...

    Citation Envoyé par chamamo Voir le message
    Je compte passer exclusivement par des interfaces pour rendre mon application testable (IView View, IViewModel ViewModel, IService Service...), devrais-je mettre l'interface avec son implémentation dans le même assembly? ou plutôt un assembly que pour les interfaces?
    Tu peux mettre les interfaces dans l'assembly commun pour les centraliser.

    Citation Envoyé par chamamo Voir le message
    Je compte m'orienter vers Prism pour la modularité (je ne sais si c'est la meilleure façon de le faire), d’après ce que je viens de décrire, est ce qu'un module métier correspond à un module Prism?
    Là par contre je ne saurais pas te répondre, car je n'ai jamais utilisé Prism.

  3. #3
    Membre éclairé Avatar de chamamo
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    588
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 588
    Points : 735
    Points
    735
    Par défaut
    Je tiens à te remercier pour tes réponses.

    Citation Envoyé par DotNetMatt Voir le message

    - Common
    --- Interfaces
    --- Security
    --- Controls
    --- Tools
    --- ...
    - ModuleA
    --- Views
    --- ViewModels
    --- Models
    - ModuleB
    --- Views
    --- ViewModels
    --- Models
    - ModuleC
    --- Views
    --- ViewModels
    --- Models
    j'étais déjà parti sur cette architecture, je me demandais si c'était la bonne approche

    Citation Envoyé par DotNetMatt Voir le message
    tu peux également rajouter un projet pour la DAL, de manière à factoriser un maximum. Si chaque module utilise une DB différente, alors chaque module devra avoir sa propre DAL.
    La couche est déjà faite, c'est générique comme couche (Repositories, Contexts), et chaque module aura ses propres Service (qui utiliseront les repositories et le contxt générique de la couche DAL Commun).

    Citation Envoyé par DotNetMatt Voir le message
    Tu peux mettre les interfaces dans l'assembly commun pour les centraliser.
    Ce n'est pas bête, ça me permettra de d'avoir un assembly rien que pour les interfaces, et deux assemblies par module (ModuleA, ModulesA.Tests)

    Reste à savoir, Je vais tout implémenter sous WPF pour commencer, avec la possibilité de passer par la suite sous Silverlight, dans ce cas je pense que je vais mettre deux assemblies par module, ModuleA et ModuleA.WPF, ce dernier contiendra l'implémentation des vues sous WPF, le jour ou je passerai sous Silverlight, il aura un troisième asembly ModuleA.Silverlight, qu'en pensez-vous?

    S'il y a d'autres idées je suis preneur.

  4. #4
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 742
    Points
    9 742
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par chamamo Voir le message
    Reste à savoir, Je vais tout implémenter sous WPF pour commencer, avec la possibilité de passer par la suite sous Silverlight, dans ce cas je pense que je vais mettre deux assemblies par module, ModuleA et ModuleA.WPF, ce dernier contiendra l'implémentation des vues sous WPF, le jour ou je passerai sous Silverlight, il aura un troisième asembly ModuleA.Silverlight, qu'en pensez-vous?
    A priori, il doit être possible de faire varier juste l'UI. Pour chaque module, les ViewModels et les Models peuvent rester en commun, avec peut-être quelques ajustements. Mais c'est là l'intérêt de ce genre de pattern Ici on ne ferait donc varier que le V de View, le M et le VM restant communs. Donc je ferais plutôt quelque chose comme ça :

    - Common
    --- Interfaces
    --- Security
    --- Controls
    --- Tools
    --- ...

    - ModuleA.SilverlightUI
    --- Views
    - ModuleA.WPFUI
    --- Views
    - ModuleA.Base
    --- ViewModels
    --- Models

    - ModuleB.SilverlightUI
    --- Views
    - ModuleB.WPFUI
    --- Views
    - ModuleB.Base
    --- ViewModels
    --- Models

    - ModuleC.SilverlightUI
    --- Views
    - ModuleC.WPFUI
    --- Views
    - ModuleC.Base
    --- ViewModels
    --- Models

  5. #5
    Membre éclairé Avatar de chamamo
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    588
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 588
    Points : 735
    Points
    735
    Par défaut
    C'est exactement ce que j'ai dit, il me manquait juste un schéma

    Ça me rassure que je ne suis pas le seul qui voit les choses comme ça, merci DotNetMatt

    Après il me reste la modularité (que ce soit avec Prism ou autres)

  6. #6
    Membre confirmé

    Profil pro
    Développeur .NET
    Inscrit en
    Août 2004
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Août 2004
    Messages : 178
    Points : 648
    Points
    648
    Par défaut
    Bonjour,

    Je me permets de rebondir sur ce sujet car j'ai une problématique similaire.

    Je précise que je commence tout juste à me mettre à du WPF/MVVM.

    Jusqu'à présent, nos projets Winforms étaient basés sur cette architecture multicouche:
    http://immobilis.developpez.com/arti...ouche-asp-net/

    Avec MVVM, j'essaie de retrouver mes petits, les tutoriaux brouillons sur google ne manquant pas, j'ai un peu de mal.

    Déjà tous les exemples que j'ai pu trouvé regroupaient tout dans le même projet.

    Je suis donc déjà content de voir que l'on peut éclater ceci en plusieurs assembly.

    Si je fais donc le rapprochement entre mon architecture et MVVM, les DTOs correspondent aux Models, la couche BLL (Business) correspond aux ViewModels, la couche DAL correspond aux repository, et enfin la couche IHM correspond aux views.

    Ai-je bien saisi le message ? (Et franchement, n'auraient-ils pas pu garder le même nom ? )

    Donc là j'ai envie de proposer un cas concret d'architecture et de te demander ton avis Matt, pour voir si j'ai bien compris.

    Imaginons un projet lambda, avec une BDD, un back office, et des webservices.

    J'ai mis les références sur le screen pour vérifier si c'est juste. Il manque un projet webservice, mais je suppose qu'il suffirait qu'il référence ViewModel et Model pour fonctionner ?
    Images attachées Images attachées  

  7. #7
    Membre éclairé Avatar de chamamo
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    588
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 588
    Points : 735
    Points
    735
    Par défaut
    Je commence moi aussi à bosser sur une telle architecture, je me permets de te répondre avec le peu de connaissance que j'ai sur le sujet.

    Pour moi le BLL ne correspond pas aux viewModels, le viewModel c'est juste une abstraction de la vue, ou on trouve seulement les attributs et les événements (Commands, Propriétés..)

    Le ViewModel récupère les données en appelant la couche BLL (appelés généralement Services) et les transmet à la vue.

    - Pour les webservices, je ne vois pas l'utilité de référencer les ViewModels, c'est une DAL si on veut, car à travers les services tu peux interroger les données, les modifier, insérer et supprimer. Sur un projet similaire j'ai fait deux repositories génériques, l'un pour l'accès à une base de donnés Repository<T> et l'autres pour les WebServices WebRepository<T>.

    J'aimerais aussi avoir d'autres avis sur le sujet.

  8. #8
    Membre confirmé

    Profil pro
    Développeur .NET
    Inscrit en
    Août 2004
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Août 2004
    Messages : 178
    Points : 648
    Points
    648
    Par défaut
    Si dans ViewModel, il n'y a pas de règles métiers, j'ai tout compris à l'envers.
    Dans ce cas il faut créer un assembly supplémentaire qui gère les règles métiers ?
    Dans les webservices je référençais ViewModel car je croyais que c'était l'équivalent d'une BLL.

  9. #9
    Membre éclairé Avatar de chamamo
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    588
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 588
    Points : 735
    Points
    735
    Par défaut
    - Pour moi le ViewModel expose des attributs et des Commandes, instancier d'autres ViewModels...etc.

    - Moi j'ai rajouté un assembly que j'ai Appelé ServiceLayer (ou BLL si tu veux) qui fait appel aux repositories ou je mets mon code métiers, comme ça je reste in dépendant de mon ViewModel. Le but et de rendre mon code métier réutilisable (dans des services Web par exemple).

    -J'ai même séparé les ViewModels et les Views, mes viewModels ne savent pas en quoi l'IHM est développé (Silverlight, WPF...)

    Pour résumer:: un assembly pour les vues, un pour les ViewModel, un pour la BLL, un pour les repository (si je passe par exemple d'entité framework à NHIBERNATE par exemple) et un pour les models.

    Dans les exemples à travers le net il y a un peu de tout, le principe est la mais on tombe rarement sur l'architecture la séparation...etc.

    C'est le résultat de mes recherches, je peux me tromper, comme toi j'attends d'autres avis

  10. #10
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 742
    Points
    9 742
    Billets dans le blog
    3
    Par défaut
    Ha, vaste sujet !

    Effectivement il y a plusieurs façons d'envisager la chose. Tout étant étroitement lié au besoin final. Certains besoins exigeront une modularité forte, alors que d'autres pourront s'en passer.

    Pour une forte modularité, il vaut mieux effectivement découper au maximum les différentes couches : on compartimente (attention, il y a des limites à la modularité). A l'inverse, si cela n'est pas nécessaire, on va essayer de regrouper afin de ne pas créer de la complexité pour rien, car oui, la modularité, ça se peut se payer très cher.

    Donc il n'y a pas de réponse toute faite à apporter, sinon ça serait trop facile

    Concernant l'architecture de Reward :

    Ton IHM ne devrait pas avoir de lien avec les Models. C'est un peu le principe d'avoir une IHM qui ne communique pas avec la DAL, puisque c'est le rôle de la BLL. Donc tu devrais avoir quelque chose comme ça :

    MVVM.DAL --> MVVM.Models --> MVVM.ViewModels --> MVVM.IHM

    Donc :
    - MVVM.IHM ne doit référencer que MVVM.ViewModels.
    - MVVM.ViewModels ne doit référencer que MVVM.Models.
    - MVVM.Models ne doit référencer que MVVM.DAL (on pourrait d'ailleurs fusionner les deux).

    Chamamo sur le ViewModel tu as en partie raison. Je dis en partie car ton découpage répond à ton besoin (qui nécessite de la modularité et la possibilité d'être porté sur différentes technos). En revanche pour des besoins plus classiques, je pense que le ViewModel peut intégrer la couche métier en son sein, en plus de remplir son rôle d'abstraction des vues.

    Tout dépend comment Reward envisage son projet... Si on se contente de la capture d'écran, on pourrait très bien découper le projet MVVM.ViewModels en deux dossiers :

    MVVM.ViewModels
    -- ViewModels
    ---- PersonViewModel.cs
    -- Business
    ---- PersonBusiness.cs

    En-dessous, on peut avoir soit un projet Model qui inclut la DAL :

    MVVM.Models
    -- PersonModel.cs

    MVVM.DAL
    -- PersonRepository.cs

    Soit un projet Model et un projet DAL :

    MVVM.Models
    -- Models
    ---- PersonModel.cs
    -- DataAccess
    ---- PersonRepository.cs

    Là avec le peu d'infos qu'on a il est difficile d'apporter une réponse claire et précise. Il faut partir de l'image la plus éloignée possible du projet (la plus macro), c'est-à-dire quels sont les gros points du projet. Puis on se rapproche au fur et à mesure pour augmenter le niveau de détails et arriver à une archi plus précise.

    Ce qu'il faut, c'est bien respecter les règles de base correspondant au design pattern choisi, et surtout rester cohérent.

  11. #11
    Membre éclairé Avatar de chamamo
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    588
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 588
    Points : 735
    Points
    735
    Par défaut
    DotNetMatt: Merci pour ces précisions utiles, la plupart des choses qu'on trouve sur internet ne traitent pas le sujet.

    C'est vrai que je suis devenu très sensible à la modularité d'après ma petite expérience, le jour ou on te demande de changer de techno tu es content d'avoir choisir cette architecture (et oui les gens changent souvent d'avis), du coup j'anticipe cela, mais c'est vrai il ne faut pas abuser. Ça peut être aussi mon passe temps en ce moment, je fais du MVVM avec le CrossPlatforme, ca me permet de rester indépendant de l'IHM .

  12. #12
    Membre confirmé

    Profil pro
    Développeur .NET
    Inscrit en
    Août 2004
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Août 2004
    Messages : 178
    Points : 648
    Points
    648
    Par défaut
    C'est intéressant bien qu'un peu complexe.

    Tout d'abord merci de vos réponses à vous deux.

    J'aimerais poursuivre la réflexion, et pour plus de clarté, ma référence en cours pour l'instant c'est cet article:
    http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

    Concernant le référencement de Models dans IHM, effectivement je me suis trompé. Et pour cause : dans une archi n couche telle que présentée dans l'article de Immobilis, la couche DTO est transverse et commune à DAL, BLL et IHM, afin de transmettre les objets dans toutes les couches.
    Assimilant un Model à un DTO j'ai fais une erreur.

    Je comprends donc bien que c'est le ViewModel uniquement qui doit être référencé dans l'IHM pour faire remonter les propriétés du Model indirectement de cette manière:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
     public string FirstName
            {
                get { return _customer.FirstName; }
                set
                {
                    if (value == _customer.FirstName)
                        return;
     
                    _customer.FirstName = value;
     
                    base.OnPropertyChanged("FirstName");
                }
            }
    Ca c'est pour un premier point. J'ai bon ?

    En deuxième point j'ai une question: Un model doit-il se contenter d'être seulement des propriétés, comme un DTO/POCO, ou bien doit-il comporter également des méthodes comme on peut le voir ci-dessous ?


    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
    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
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
     
    using System;
    using System.ComponentModel;
    using System.Diagnostics;
    using System.Text.RegularExpressions;
    using DemoApp.Properties;
     
    namespace DemoApp.Model
    {
        /// <summary>
        /// Represents a customer of a company.  This class
        /// has built-in validation logic. It is wrapped
        /// by the CustomerViewModel class, which enables it to
        /// be easily displayed and edited by a WPF user interface.
        /// </summary>
        public class Customer : IDataErrorInfo
        {
            public static Customer CreateNewCustomer()
            {
                return new Customer();
            }
     
            public static Customer CreateCustomer(
                double totalSales,
                string firstName,
                string lastName,
                bool isCompany,
                string email)
            {
                return new Customer
                {
                    TotalSales = totalSales,
                    FirstName = firstName,
                    LastName = lastName,
                    IsCompany = isCompany,
                    Email = email
                };
            }
     
            protected Customer()
            {
            }
     
            public string Email { get; set; }
     
            public string FirstName { get; set; }
     
            public bool IsCompany { get; set; }
     
            public string LastName { get; set; }
     
            public double TotalSales { get; private set; }     
     
            string IDataErrorInfo.Error { get { return null; } }
     
            string IDataErrorInfo.this[string propertyName]
            {
                get { return this.GetValidationError(propertyName); }
            }
     
            public bool IsValid
            {
                get
                {
                    foreach (string property in ValidatedProperties)
                        if (GetValidationError(property) != null)
                            return false;
     
                    return true;
                }
            }
     
            static readonly string[] ValidatedProperties = 
            { 
                "Email", 
                "FirstName", 
                "LastName",
            };
     
            string GetValidationError(string propertyName)
            {
                if (Array.IndexOf(ValidatedProperties, propertyName) < 0)
                    return null;
     
                string error = null;
     
                switch (propertyName)
                {
                    case "Email":
                        error = this.ValidateEmail();
                        break;
     
                    case "FirstName":
                        error = this.ValidateFirstName();
                        break;
     
                    case "LastName":
                        error = this.ValidateLastName();
                        break;
     
                    default:
                        Debug.Fail("Unexpected property being validated on Customer: " + propertyName);
                        break;
                }
     
                return error;
            }
     
            string ValidateEmail()
            {
                if (IsStringMissing(this.Email))
                {
                    return Strings.Customer_Error_MissingEmail;
                }
                else if (!IsValidEmailAddress(this.Email))
                {
                    return Strings.Customer_Error_InvalidEmail;
                }
                return null;
            }
     
            string ValidateFirstName()
            {
                if (IsStringMissing(this.FirstName))
                {
                    return Strings.Customer_Error_MissingFirstName;
                }
                return null;
            }
     
            string ValidateLastName()
            {
                if (this.IsCompany)
                {
                    if (!IsStringMissing(this.LastName))
                        return Strings.Customer_Error_CompanyHasNoLastName;
                }
                else
                {
                    if (IsStringMissing(this.LastName))
                        return Strings.Customer_Error_MissingLastName;
                }
                return null;
            }
     
            static bool IsStringMissing(string value)
            {
                return
                    String.IsNullOrEmpty(value) ||
                    value.Trim() == String.Empty;
            }
     
            static bool IsValidEmailAddress(string email)
            {
                if (IsStringMissing(email))
                    return false;
     
                // This regex pattern came from: http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx
                string pattern = @"^(?!\.)(""([^""\r\\]|\\[""\r\\])*""|([-a-z0-9!#$%&'*+/=?^_`{|}~]|(?<!\.)\.)*)(?<!\.)@[a-z0-9][\w\.-]*[a-z0-9]\.[a-z][a-z\.]*[a-z]$";
     
                return Regex.IsMatch(email, pattern, RegexOptions.IgnoreCase);
            }	
        }
    }
    Cela me perturbe, car en fait, j'aurais eu une tendance naturelle à ne pas mettre les règles de validation dans le Model, mais plutôt dans le viewModel. Mais après le point fait par Matt:

    MVVM.ViewModels
    -- ViewModels
    ---- PersonViewModel.cs
    -- Business
    ---- PersonBusiness.cs
    j'aurais plutôt tendance à mettre ça dans ... PersonBusiness. Erreur ou pas ?

    J'ai encore d'autres questions mais j'y vais doucement

  13. #13
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 742
    Points
    9 742
    Billets dans le blog
    3
    Par défaut
    MVVM peut être comparé à MVC et à MVP, même s'il y a quelques différences. Officiellement, voici ce que doivent contenir les couches :
    - Model = Business Logic + Data
    - ViewModel = Presentation Logic
    - View = UI + UI Logic

    En pratique, la Business Logic se trouve plus souvent dans le ViewModel. On ne trouve dans le Model que de la validation ou des choses comme ça. Encore une fois, tout dépend du projet, mais c'est ce que j'ai pu constater dans l'ensemble.

    Le ViewModel encapsule les données (qui viennent du M) et la logique de présentation (qui sera utilisée par le V). Il n'a aucune référence vers le V, et ne sait donc pas quelle est la View qui va le consommer. C'est là qu'on met les commandes et les propriétés sur lesquelles on va binder la View, afin de pouvoir faire transiter les infos, dans les deux sens : la View peut mettre à jour des données, mais aussi être notifiée qu'une donnée a changé dans la source de données. Donc en gros, le VM définit les fonctionnalités qui sont proposées à la View, mais c'est ensuite la View qui définira le rendu à l'écran.

    Quelques liens pour approfondir :
    - Implementing the MVVM Pattern (je pense que c'est l'article qui explique le mieux)
    - Model View ViewModel
    - Model-View-ViewModel (MVVM) Explained

    Pour ton premier point, oui ça semble bien implémenté, mais un avis sur une seule propriété n'est pas forcément pertinent

    Pour le second point, je t'ai donné la réponse ci-dessus

  14. #14
    Membre confirmé

    Profil pro
    Développeur .NET
    Inscrit en
    Août 2004
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Août 2004
    Messages : 178
    Points : 648
    Points
    648
    Par défaut
    Merci pour tes réponses, je vais m'atteler à la lecture de ton premier lien.

    Je vais corser un peu les choses.
    Sachant que:
    • La commande pour sauver un client se trouve dans un ViewModel.

    • La validation des données se trouve dans le Model.

    • Officiellement, la couche métier se trouve aussi dans le Model, ainsi que la DAL.



    Si j'ai une couche WebService devant permettre de sauver un client, est-ce que mon WS référence uniquement le modèle ?

    Et je me permets un schéma histoire d'essayer d'être clair:


    Donc on a les couches concernant l'IHM: Views et ViewModels.

    Puis on a la couche Models, découpées en 3 modules de sorte que:
    - Models, contenant par exemple un CustomerModel, avec ses propriétés et ses règles de validation.
    - ViewModel s'adresse à BLL qui fait transiter les CustomerModel et s'occupe des process métiers, ex : ManagerCustomer.CreateCustomer
    - BLL s'adresse à la DAL qui s'occupe des opérations type CRUD, par exemple en sauvegardant un Customer : ProviderCustomer.AddCustomer.

    En couche "haute", on a WS (Webservice), qui référencera Model, et attaquera la BLL pour ajouter un client.

    Ai-je bon ? En espérant avoir été clair

    Je vais lire ton article, encore merci .
    Images attachées Images attachées  

  15. #15
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2006
    Messages : 436
    Points : 963
    Points
    963
    Par défaut
    Ahhhh la conception d'architecture ... LE TRUC chronophage par excellence pour les perfectionnistes

    Pour ajouter ma touche, je vous conseils, je vous recommande même vivement ! D'utiliser les Portable Class Library si vous êtes dans un framework >= 4.0.

    Ainsi, un projet silverlight, wpf et win phones peuvent référencer le même projet ViewModel (sans avoir à ajouter des liens dans différents projets VM.WPF, VM.SL ...)

    Ca permet d'unifier le projet d'interface qui peut être directement ajouter à silverlight ou winform ou autre.

    Ca permet d'avoir une couche helper commune etc

    Bref ça vous simplifie la vie ... Depuis que j'ai découvert ça, mes DTO/POCO, Models, Interfaces, BLL TOUT est importable dans n'importe quel projet. Et ça ... Ca n'a pas de prix :')

    Edit, je conseil vivement aussi de toujours utiliser une interface ! Vous pourez utilisez des BLL prenant en entrée des IQQChose et envoyer par exemple depuis silverlight via wcf, un SLQQchose, depuis win phones WPQQchose etc.

    Ainsi il est très facile de développer des models spécif à une plateforme (par ex ajouter dans un cas de la valid dans les setter, dans d'autres lever des exceptions, dans d'autres avoir des annotations ... Un projet Windows phone implémentera par exemple IPersonne alors que WPF en client lourd implémentera IPersonne et IContact et ICourrier etc. On peut donc creuser plus profondément nos classes suivant le projet et ne pas avoir de problèmes lors de l'enregistrement en base car il prend des IMachin et pas des objets typé comme MachinDTO , MachinPOCO, MachinViewModel etc...

    (pardonné mes abus de langages j'ai écris vite fait et sans même me relire )

  16. #16
    Membre éclairé Avatar de chamamo
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    588
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 588
    Points : 735
    Points
    735
    Par défaut
    Citation Envoyé par Kikuts Voir le message
    Pour ajouter ma touche, je vous conseils, je vous recommande même vivement ! D'utiliser les Portable Class Library si vous êtes dans un framework >= 4.0.
    Effectivement c'est très pratique ce nouveau type de library, sinon on peut partager les classes avec d'autres libraries ajoutant le lien vers cette classe (Add as link).

    Citation Envoyé par Kikuts Voir le message
    Edit, je conseil vivement aussi de toujours utiliser une interface ! Vous pourez utilisez des BLL prenant en entrée des IQQChose et envoyer par exemple depuis silverlight via wcf, un SLQQchose, depuis win phones WPQQchose etc.
    Exactement (pour avoir des différentes implémentations, des tests, injections de dépendances...)

    C'est dommage qu'il n'y a pas beaucoup d'articles qui traitent ce genre de sujet (j'en ai marre de voir des articles avec un seule Assembly, un model, un viewModel, afficher les listes Customers... )

  17. #17
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 742
    Points
    9 742
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par Reward Voir le message
    Ai-je bon ? En espérant avoir été clair
    Ca a l'air cohérent en tout cas...

    Tu pourrais aussi choisir d'isoler le gros de la couche Business dans un autre projet. Tu la consommes directement depuis le WS, et au niveau du Model tu aurais toujours ton fichier Business qui ferait appel à la couche Business, et qui incluerait les éventuels traitements spécifiques au MVVM.

    A toi de choisir ce qui te semble le plus pertinent.

  18. #18
    Membre confirmé

    Profil pro
    Développeur .NET
    Inscrit en
    Août 2004
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Août 2004
    Messages : 178
    Points : 648
    Points
    648
    Par défaut
    Ha pas mal ! Je n'avais pas pensé à faire ça.

    Merci Matt pour tes interventions

  19. #19
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2006
    Messages : 436
    Points : 963
    Points
    963
    Par défaut
    Citation Envoyé par chamamo Voir le message
    C'est dommage qu'il n'y a pas beaucoup d'articles qui traitent ce genre de sujet (j'en ai marre de voir des articles avec un seule Assembly, un model, un viewModel, afficher les listes Customers... )

    Oui et je me demande pourquoi aucun tuto, projet d'exemple n'utilise une architecture digne de ce nom. Ce genre de problématique se pose systématiquement et on ne trouve jamais rien sur le net. C'est souvent tout seul et en se baladant de lien en lien qu'on tombe sur une parcelle de code intéressant ...

    Comme on dit "i know that feel bro"

  20. #20
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 742
    Points
    9 742
    Billets dans le blog
    3
    Par défaut
    Le sujet m'a inspiré donc j'ai commencé un article sur mon blog. Je prépare les exemples de code liés aux diagrammes, mais ça prend du temps Ils seront postés dès qu'ils seront prêts, j'espère avant le week-end prochain.

Discussions similaires

  1. Réponses: 0
    Dernier message: 25/05/2013, 23h03
  2. Avis architecture d'une application modulaire
    Par mactwist69 dans le forum Architecture
    Réponses: 6
    Dernier message: 22/12/2012, 17h13
  3. Réponses: 7
    Dernier message: 16/06/2007, 13h03
  4. Architecture d'une application Web
    Par le Daoud dans le forum Développement Web en Java
    Réponses: 7
    Dernier message: 05/10/2006, 12h39
  5. Comment faire une application modulaire
    Par JuJu° dans le forum C++Builder
    Réponses: 3
    Dernier message: 04/08/2006, 12h35

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo