Publicité
+ Répondre à la discussion
Page 2 sur 3 PremièrePremière 123 DernièreDernière
Affichage des résultats 21 à 40 sur 43
  1. #21
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    101
    Détails du profil
    Informations personnelles :
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : septembre 2004
    Messages : 101
    Points : 60
    Points
    60

    Par défaut

    En fait, je pars dans l'optique de ne pas créer de VO/DTO...
    Actuellement, j'imagine donc utiliser mes objets métiers dans mes couches supérieures de deux façons :
    - Comme conteneur de données (pour l'affichage des valeurs de mon objet, par exemple)
    - Comme conteneur de critéres de recherche (pour le filtrage)

    Par rapport à ce que vous dites, je n'ai peut-être pas suffisamment de connaissances (ou de scrupule ) par rapport à certains 'design pattern', mais cela ne géne pas d'avoir des couches supérieures (application et IHM) totalement dépendante de ma couche métier.

    L'intérêt que j'y vois est que mes classes métiers possède une intelligence élevée et qu'elles sont donc autonomes et utilisables dans les couches supérieures (et je n'implémente pas de classe de type (VO/DTO))

    Concernant l'accés aux données, étant donné que je n'utilise pas d'outil ORM (manque de temps pour apprendre à les utiliser , à moins que quelqu'un en connaisse un simple et efficace ), je n'ai pas de scrupule à ce que mes classe métiers soit dépendante de mes classes d'accés aux données (DAO).



    --Avis au lecteurs--
    Je n'en suis toujours (plus ou moins) qu'à un niveau théorique et mon expérience sur la conception en couche ne date que d'une semaine, donc prenez ce post avec précautions

  2. #22
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut

    Je signale à tous ceux qui sont intéressés par le développement en couche l'existence d'un framework gratuit Dot.Net spécifiquement conçu, pour ce que j'en ai compris, pour faciliter le développement de la couche métier.

    http://www.lhotka.net/Area.aspx?id=4#
    http://www.primos.com.au/primos/Defa...ID=50&tabid=67

  3. #23
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    101
    Détails du profil
    Informations personnelles :
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : septembre 2004
    Messages : 101
    Points : 60
    Points
    60

    Par défaut

    Merci

    Tu l'as testé ?

  4. #24
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut

    Non, mais j'ai commandé le livre, que je devrais bientôt recevoir.

  5. #25
    Membre Expert Avatar de FRED.G
    Inscrit en
    novembre 2002
    Messages
    1 029
    Détails du profil
    Informations personnelles :
    Âge : 34

    Informations forums :
    Inscription : novembre 2002
    Messages : 1 029
    Points : 1 372
    Points
    1 372

    Par défaut

    Salut à tous !

    Merci Promeneur pour le lien. Je ne peux pas regarder tout de suite mais ça a l'air sérieux (bouquins, support du FX 3.0, site et doc complets, etc.).
    (\ _ /)
    (='.'=)
    (")-(")

  6. #26
    Membre Expert Avatar de Mose
    Inscrit en
    janvier 2006
    Messages
    1 143
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 143
    Points : 1 266
    Points
    1 266

    Par défaut

    Un post intéressant !
    Néanmoins j'ai un peu de mal à comprendre ce que vous appelez contrôleurs applicatifs. Un exemple ?

  7. #27
    Membre régulier
    Développeur informatique
    Inscrit en
    mars 2005
    Messages
    110
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2005
    Messages : 110
    Points : 78
    Points
    78

    Par défaut

    Salut,
    si je ne me trompe les contrôleurs applicatifs sont les contrôleurs qui gèrent un cas utilisateur (use case en anglais).
    par exemple considère le problème où tu passes une commande

    le controleur applicatif va offrir des métodes pour réaliser le use case. Des évennements dans l'IHM vont pouvoir déclenché leur éxécution.
    Code c# :
    1
    2
    3
    4
    void ChoisirItem(Item unItem)
    void EnleverItem(Item unItem)
    void PayerCommande()
    Argent GetCommandePrix() // un mauvais example en fait

    Le controlleur applicatif va ensuite utilisé les objets métiers ou encore une couche d'indirection (ici j'utilise directement un modèle métier riche et la persistance est assurée par un manager recu par le controleur lors de son initialisation par injection)
    example pour trouver le prix de la commande
    Code c# :
    1
    2
    3
    4
    GetCommandePrix() {
      //eventuelles pre cond 
      return currentCommande.GetTotal()  //une commande est une classe entité
    }
    et la couche métier va faire son travail dans la classe Commande
    Code c# :
    1
    2
    3
    4
    Argent getTotal(){
    IPrixStrategy ps = PrixStrategyFactory.Instance // une strategy (GoF) hypotetique
    return ps.GetPrix(this)
    }

    une strategy peut alors calculer le prix sans que le client ne voient des règles compliquées comme 10% de réduc sur le produit A, calcul des cout de transport, reduction membre, promotion de noel. Tout ca en déléguant bien sûr à des services compétants :-)

    Vraiment pas sûr là: l'utilité d'un controleur métier peut être de coordonner des actions complexes et peu relatées.
    par example pour valider un commande il faut coordonner la mises à jours des stocks, une autorisation de cartes bancaires, une commande de transport, etc

    Voilà en espérant de ne pas m'être trompé et que ca t'as éclairé :-)
    Dom

  8. #28
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 58
    Points
    58

    Par défaut

    Hello,

    Je vous livre quelques compléments sur l'architecture que j'ai adopté depuis quelques mois (basée sur .NET)
    Je me suis bcp basé sur l'excellent PetShop v.4 de Microsoft et sur celui de DNG.
    Plusieurs couches au rendez-vous :
    Présentation (IHM + codeBehind)
    Facade (interfaces des services)
    Services ( c'est l'équivalent des controleurs de cas d'utilisation)
    BLL ( = la couche d'objets métiers. Ils contiennent la logique métier, les méthodes métiers, et des méthodes statiques (finders etc...))
    DAO ( = couche d'accès aux données, basée sur NHibernate)

    Une couche est transversale à toutes celles-ci : la couche Model. Il s'agit des objets du domaine. Ils ne contiennent pas de logique métier et sont sérializables, ce qui permet de les manipuler dans la couche IHM, même si celle-ci se situe sur un serveur différent que les autres couches (techniques de Remoting ou WebServices).

    Je n'ai pas mis en oeuvre d'IOC pour l'instant dans mon architecture. C'est une évolution à prévoir.
    Attention à l'utilisation d'un framework de persistance lors de l'utilisation sur des tiers phyisques différents ! (prévoir des DTO pour éviter d'embarquer la logique de mapping avec vos entités métiers, ou rajouter des méthodes dans vos services qui permettent d'initialiser vos collections définies en lazy-loading)
    Sinon ça va vous péter à la figure

    @+

  9. #29
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut

    Citation Envoyé par djflex68
    Je me suis bcp basé sur l'excellent PetShop v.4 de Microsoft
    Où est-ce qu'on le trouve ? merci

  10. #30
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 58
    Points
    58

  11. #31
    Membre habitué
    Inscrit en
    avril 2005
    Messages
    206
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 206
    Points : 103
    Points
    103

    Par défaut

    merci

  12. #32
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 58
    Points
    58

    Par défaut

    Hello,

    Je reposte quelques mois plus tard pour vous faire part de mes choix.
    Après plusieurs essais d'architectures, j'ai abouti à un modèle qui parait assez solide. J'aimerais savoir ce que vous en pensez.



    Quelques explications :
    Une couches Model (mon modèle d'entités = les POCO)
    Une couche IHM (les pages ...)
    Une couche Adaptation optionnelle (je l'utilise pour convertir mes objets Model en objets composites "linéaires" utilisables dans des GridView (DataGrid) .NET par exemple)
    Une couche Facade optionnelle : il s'agit des interfaces de ma couche Service partagés par le client et le serveur.
    Une couche Service optionnelle : il s'agit d'identifier des services qui pourraient être utlisées dans d'autres applications (démarche SOA). Ces services regroupent des grosses fonctionnalités comme une structure hiérarchique d'une entreprise par exemple...
    Une couche IBLL : Ce sont les interfaces de la couche BLL partagés par le client et le serveur.
    Une couche BLL : elle contient les managers (contrôlent les opérations CRUD et Finders sur les entités métiers). Elle contient également les objets métiers (qui sont réponsables des traitements métiers).
    Une couche DAO : ce sont les objets d'accès aux données.
    Les couches sont réparties sur plusieurs serveurs (3-tier)
    IHM & Adaptation : Serveur Web ou Winforms (client)
    Service, BLL, DAO : Serveur applicatif (serveur)
    Model, IBLL et Facade sont partagés entre les serveurs.

    Comme j'utilise NHibernate pour gérer l'accès aux données, j'ai implémenté un DynamicProxy pour ouvrir et fermer automatiquement les sessions. Ce dynamic proxy est instancié lors de l'appel à la couche Service ou BLL. J'ai reproduit le modèle proposé par Sami Jaber dans son excellent article intitulé
    Conception n-tiers et mapping objet/relationnel avec .NET et J2EE

    Voilà, j'attends vos remarques avec impatience

  13. #33
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 483
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 483
    Points : 7 184
    Points
    7 184

    Par défaut

    Salut,

    Pourquoi considérer les interfaces comme une couche? Le principe d'une architecture en couches est de n'autoriser la communication qu'avec le voisin du dessus et du dessus.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  14. #34
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 58
    Points
    58

    Par défaut

    parce qu'elles se distribuent plus facilement (ex. référence d'assembly en .NET)

  15. #35
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 483
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 483
    Points : 7 184
    Points
    7 184

    Par défaut

    Citation Envoyé par Immobilis Voir le message
    Le principe d'une architecture en couches est de n'autoriser la communication qu'avec le voisin du dessus et du dessus.
    Tu veux dire que tu fais un projet uniquement avec des interfaces?
    Merci

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  16. #36
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 58
    Points
    58

    Par défaut

    oui, et c'est d'ailleurs le seul moyen de faire lorsque tu fais du remoting par exemple. En gros tu crées un proxy sur tes objets métiers que tu manipules via les interfaces de ces objets métiers. Du coup pour avoir accès à ces interfaces à la fois côté client et côté serveur, tu es obligé d'avoir une DLL contenant ces interfaces d'un côté et de l'autre.

  17. #37
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 483
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 483
    Points : 7 184
    Points
    7 184

    Par défaut

    Aurais-tu un argument convainquant pour justifier la séparation d'un objet de ses méthodes
    Mettons l'objet suivant:
    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
    using System;
    using System.Collections.Generic;
    using System.Text;
    using System.Xml;
    using System.Xml.Serialization;
    
    namespace Immobilis.EComm.BO
    {
        [Serializable]
        [XmlRootAttribute]
        public class Obj1
        {
            private int _proId;
    
            [XmlElement]
            public int ProId
            {
                get { return _proId; }
                set { _proId = value; }
            }
    
            private string _nom;
    
            [XmlElement]
            public string Nom
            {
                get { return _nom; }
                set { _nom = value; }
            }
    
        }
    }
    Pourquoi ne devrais-je pas avoir à l'interieur les méthodes qui me permettent de le remplir selon un id, puis de le mettre à jour ou de le supprimer ou encore d'en faire une collection? Un objet est de toutes façons fortement couplé à son implémentation, non?

    Je cherche des arguments convaincants

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  18. #38
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 483
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 483
    Points : 7 184
    Points
    7 184

    Par défaut

    Citation Envoyé par djflex68 Voir le message
    pour avoir accès à ces interfaces à la fois côté client et côté serveur
    Dans une application de quel type? Je ne comprend pas.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  19. #39
    Membre du Club
    Inscrit en
    octobre 2004
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : octobre 2004
    Messages : 124
    Points : 58
    Points
    58

    Par défaut

    Dans une application de quel type? Je ne comprend pas.
    Dans une application distribuée, c'est à dire quand le code métier est déporté sur un serveur applicatif. En gros soit tu fais du 2-tier, c'est à dire que tout ton code est installé au même endroit (ex. un serveur Web = 1 tier) et tu as une base de données à part ( = le 2eme tier), ou alors tu fais du 3-tier et tu as la partie graphique sur un tier (ex. pages ASPX sur un serveur Web), la partie métier sur un serveur applicatif (avec le code et la logique métier), et la partie BDD sur un 3eme tier. Dans ce cas, pour appeler des méthodes à distance entre serveur Web et serveur applicatif, il te faut un moyen d'instancier tes objets à distance = le .NET Remoting (ou RMI en Java).
    C'est pour cela qu'il faut que le serveur Web ET le serveur applicatif partagent les interfaces des objets, tu n'as pas d'avoir le code de ces objets côté serveur Web par exemple, seules les interface suffisent, puisque le code réside en fait sur le serveur applicatif.

    Aurais-tu un argument convainquant pour justifier la séparation d'un objet de ses méthodes
    Il y a deux articles qui devraient te convaincre de séparer tes objets en objets métiers (avec du code métier) et objets du domaine (structures de données).
    D'abord l'article de ego, très facile à lire, et tu as pas mal d'arguments dedans :
    http://ego.developpez.com/uml/tutori...ments-v1.2.pdf
    Ensuite DNG propose des articles qui parlent de cette façon de faire.
    Et enfin, regarde du côté du PetShop 4.0 de Microsoft, c'est un exemple d'application et de "best practices" dans le cas d'une application .NET (mais les concepts se valent également dans une application Java). Tu verras qu'il préconisent également cette façon de faire (couche Model avec objets de type "structure de données", et objets métiers dans la couche BLL).

    Bonne lecture

    @+

  20. #40
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 483
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 483
    Points : 7 184
    Points
    7 184

    Par défaut

    Cool merci.

    Ceci dit, il apparait que la création d'un modèle indépendant des couches se base sur le postulat: "c'est le concept fondamental de la programmation orientée objet". Autrement dit c'est une donc bonne façon de faire.

    Toutefois, si je comprend bien qu'il faut faire confiance à l'exéperience, y a-t-il un cas concret démontrant qu'il est préférable de faire ainsi? Je dois trouver une approche pédagogique convaincante.

    Par exemple, je joins un diagramme de classe avec un objet "modèle" et des classe permettant l'allocation de sa propriété "Libelle". Deux héritent du modèle. Chacune des méthodes alloue la propriété de façon différentes (dans l'exemple la chaine n'aura pas la même valeur). Le nom des méthodes est toujours le même (AllocateLibelle), du coup j'aurais pu utiliser une interface.

    Quelles critiques feriez-vous? Laquelle est plus facile à utiliser, faire évoluer?
    Le code de (le namespace devrait être Immobilis.EComm.Bll mais c'est pas grave)
    • Obj
    • ObjImplement1
    • ObjImplement2
    • ObjImplement3
    • Program

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    using System;
    using System.Collections.Generic;
    using System.Text;
    
    namespace Immobilis.EComm.BO
    {
        public class Obj
        {
            private string _libelle;
        
            public string Libelle
            {
                get
                {
                    return _libelle;
                }
                set
                {
                    _libelle = value;
                }
            }
        }
    }
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    using System;
    using System.Collections.Generic;
    using System.Text;
    
    namespace Immobilis.EComm.BO
    {
        public class ObjImplement1 : Obj
        {
            public void AllocateLibelle()
            {
                this.Libelle = "Immo";
            }
        }
    }
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    using System;
    using System.Collections.Generic;
    using System.Text;
    
    namespace Immobilis.EComm.BO
    {
        public class ObjImplement2 : Obj
        {
            public void AllocateLibelle()
            {
                this.Libelle = "Bilis";
            }
        }
    }
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    using System;
    using System.Collections.Generic;
    using System.Text;
    
    namespace Immobilis.EComm.BO
    {
        public class ObjImplement3
        {
            public static Obj AllocateLibelle()
            {
                Obj obj = new Obj();
                obj.Libelle = "Immobilis";
                return obj;
            }
        }
    }
    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
    using System;
    using System.Collections.Generic;
    using System.Data;
    using System.Text;
    using System.Xml;
    
    using Immobilis.EComm.BO;
    
    namespace ConsoleApplication1
    {
        public class Program
        {
            public static void Main(string[] args)
            {
                ObjImplement1 obj1 = new ObjImplement1();
                obj1.AllocateLibelle();
                Console.WriteLine(obj1.Libelle);
    
                ObjImplement2 obj2 = new ObjImplement2();
                obj2.AllocateLibelle();
                Console.WriteLine(obj2.Libelle);
    
                Obj obj3 = ObjImplement3.AllocateLibelle();
                Console.WriteLine(obj3.Libelle);
    
                Console.ReadLine();
            }
        }
    }
    Merci de votre aide.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 3 PremièrePremière 123 DernièreDernière

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •