[Architecture] Conception multi-couches [Résolu]

[Exsilius]

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

[Promeneur]

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

[Exsilius]

Merci

Tu l'as testé ?

[Promeneur]

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

[FRED.G]

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.).

[Mose]

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

[trolldom]

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

[djflex68]

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

@+

[Promeneur]

Envoyé par djflex68

Je me suis bcp basé sur l'excellent PetShop v.4 de Microsoft

Où est-ce qu'on le trouve ? merci

[djflex68]

http://msdn2.microsoft.com/en-us/library/aa479070.aspx

[Promeneur]

merci

[djflex68]

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

[Immobilis]

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+

[djflex68]

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

[Immobilis]

Envoyé par Immobilis

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+

[djflex68]

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.

[Immobilis]

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+

[Immobilis]

Envoyé par djflex68

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+

[djflex68]

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

@+

[Immobilis]

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+