Programmation en couches et problème de dépendance circulaire

Version imprimable

21/12/2011, 13h14
Kropernic

Programmation en couches et problème de dépendance circulaire

Bonjour,

Pour le dernier projet qu'il m'a été demandé de faire, je m'essaie à la programmation en couche.

J'ai donc une solution qui contient 3 projets.

Un projet pour l'interface (nommé GUI) ;
Un projet pour la couche business (nommé BLL) ;
Un projet pour la couche d'accès aux données (nommé DAL).

Mon problème se situe au niveau des références à ajouter à ces différents projets.

A l'heure ou j'écris ces lignes, le projet DAL a une référence vers le projet BLL car il a besoin de connaître les objets métier pour pouvoir les renvoyer.

De même, le projet BLL a besoin d'une référence vers le projet DAL afin de pouvoir appeler les fonctions qui récupère les infos dans la DB et retourne l'objet demander.

C'est là que ça coince. VS refuse d'ajouter cette dernière référence pour des soucis de dépendance circulaire.

Comment faut-il procéder dans ce cas ?
Y a-t-il une manière précise de faire pour chacun des projets puissent se référencer l'un l'autre ?
Faut-il que les fonctions du projet DAL se contentent de renvoyer les données de l'objet via des passages de paramètres par référence plutôt que de renvoyer un objet "fini" ?

Merci d'avance,

Griftou.
21/12/2011, 13h22
BenoitM

tu rajoutes une autre couche pour les objets métiers :)

BO Business Object ou BOL Business Objet layer ou DTO Data Transfert Object
21/12/2011, 13h25
Kropernic

???

Je ne vois pas en quoi cela va résoudre mon problème.

Cela ne va-t-il pas juste le déplacer ?
21/12/2011, 13h29
BenoitM

Tes objets seront défini dans la DTO. Cette couche est transversalle partagé par tout le monde (dal,bll,gui)

La BLL refera référence à la DTO et à la DAL
La Dal refera référence à la DTO

il y a des modèles plus complexe que la DTO partagé par toutes les autres couches par exemple ,si j'ai bien compris, tu peux avoir des BO(L) et quand tu veux sauvegarder tu transforme ton objet BO(L) en DTO et la DAL n'a connaissance que de la DTO.
Mais perso je n'ai jamais utilisé que la simple DTO
21/12/2011, 14h43
Kropernic

Ok, je crois que je vois.

Fichtre ça me fait un nouveau projet à ajouter à la solution (peanuts) et je vais devoir vérifier toutes les méthodes de mes objets pour voir si c'est bien au bon endroit (boooooooring...).

Merci.

Griftou.

P.S. : Article court mais suffisant pour comprendre ce qu'est un DTO pour ceux qui comme moi l'ignoraient.
Autre article plus complet qui détail dans un exemple pratique les différentes couches

Histoire d'être vraiment sûr, une dernière question.

Les constructeurs des objets se trouvent dans quelle couche du coup ?

D'instinct, je dirais dans la couche BLL. Mais dans la couche BLL, on doit bien créer des objets DTO. Est-ce qu'il y a d'office un constructeur "par défaut" dans toutes les classes qui ne ferait rien que renvoyer un objet vide ?
21/12/2011, 15h28
BenoitM

Le constructeur dans la Dto :)
par contre dans la BLL tu auras un GetAllEtudiant() GetEtudiantByName(string name)

et la BLL demandera à la DAL d'aller lire les informations dans la base de donnée

Un petit exemple, j'ai pas pu regarder ce qu'il vallait, je peux pas télécharger les zip au boulot :roll:

tu as aussi architecture en couche mais qui utilise en partie WPF même si pour le wpf on préfere le modèle mvvm

Merci.

J'étais donc à côté de la plaque XD.

Donc en fait, l'objet en lui-même se trouve dans la DTO

Et la BLL ne fait que transmettre cet objet de l'interface vers la DAL et inversément.

J'avoue que j'ai du mal... Je me demande si je ne suis pas en train de prendre exemple sur plusieurs façon de faire en essayant de toutes les appliquer :aie:.

Peux-tu jeter une oeil sur le premier article que je link dans le message #5.
Est-ce bien de cela que tu parles quand tu évoques les DTO ?

Sinon, voici un exemple concret :

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
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
Imports System.ComponentModel
 
Public Class Groupes
    Inherits List(Of Groupe)
 
    Implements INotifyPropertyChanged
    Public Event PropertyChanged(ByVal sender As Object, ByVal e As System.ComponentModel.PropertyChangedEventArgs) Implements System.ComponentModel.INotifyPropertyChanged.PropertyChanged
 
    Private Sub NotifyPropertyChanged(ByVal info As String)
        RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(info))
    End Sub
 
    Public Overloads Sub Add(ByVal groupe As Groupe)
        MyBase.Add(groupe)
        NotifyPropertyChanged("ListGroups")
    End Sub
 
    Public Overloads Function Find(ByVal id As Integer) As Groupe
        For Each elem As Groupe In Me
            If elem.Id = id Then
                Return elem
            End If
        Next
        Return Nothing
    End Function
 
    Public Function CommitUpdates() As Boolean
        Dim result As Boolean = False
        For Each groupe As Groupe In Me
            Select Case groupe.Status
                Case BLL.Groupe.e_status.Updated
                    If DAL.dal_Groupe.UpdateGroupe(groupe) Then
                        groupe.Status = BLL.Groupe.e_status.UpToDate
                    Else
                        Throw New Exception("")
                    End If
 
                Case BLL.Groupe.e_status.Created
 
                    If DAL.dal_Groupe.CreateGroupe(groupe) Then
                        groupe.Status = BLL.Groupe.e_status.UpToDate
                    Else
                        Throw New Exception("")
                    End If
            End Select
        Next
        Return result
    End Function
 
    Public Overloads Function Remove(ByVal groupToRemove As Groupe) As Boolean
        If Not Groupe.DeleteGroupe(groupToRemove) Then
            Throw New Exception("Impossible de supprimer ce groupe.")
            Return False
        Else
            Return MyBase.Remove(groupToRemove)
        End If
    End Function
 
    Public Shared Function GetAllgroupes() As Groupes
        Return DAL.dal_Groupe.GetAllgroupes
    End Function
 
End Class
 
 
 
Public Class Groupe
 
    Public Property Id As Integer
 
    Private _Ordre As Integer
    Public Property Ordre As Integer
        Get
            Return _Ordre
        End Get
        Set(value As Integer)
            _Ordre = value
            Me.Status = e_status.Updated
        End Set
    End Property
 
    Private _textes As Textes
    Public Property Textes As Textes
        Set(value As Textes)
            _textes = value
            Me.Status = e_status.Updated
        End Set
        Get
            Return _textes
        End Get
    End Property
 
    Private _Comptetences As List(Of Competence)
    Public Property Competences As List(Of Competence)
        Get
            Return _Comptetences
        End Get
        Set(value As List(Of Competence))
            _Comptetences = value
            Me.Status = e_status.Updated
        End Set
    End Property
 
    Public Sub New(ByVal id As Integer, ByVal textes As Textes)
        Me.Id = id
        Me.Textes = textes
    End Sub
 
    Public Sub New(ByVal textes As Textes)
        Me.Id = 0
        Me.Textes = textes
    End Sub
 
    Public Property Status As e_status
    Public Enum e_status As Integer
        UpToDate = 1
        Created = 2
        Updated = 3
    End Enum
 
    Public Shared Function NewGroupe(ByVal groupe As Groupe) As Boolean
        Return DAL_Groupe.NewGroupe(groupe)
    End Function
 
    Public Shared Function DeleteGroupe(ByVal groupe As Groupe) As Boolean
        Return DAL_Groupe.DeleteGroupe(groupe)
    End Function
 
    Public Shared Function UpdateGroupe(ByVal groupe As Groupe) As Boolean
        Return DAL_Groupe.UpdateGroupe(groupe)
    End Function
 
    Public Shared Function GetGroupeById(ByVal id As Integer) As Groupe
        Return DAL_Groupe.GetGroupeById(id)
    End Function
End Class

Ne regardes pas pour le moment les références DAL ou BLL car ce ne dois pas être juste (j'suis en train de tout refactoriser :aie:). Par contre ce qui m'intéresse, ce serait savoir où je mets ce bazarre ?

SI (et j'insiste sur le si) j'ai bien compris, je scindé cette classe en deux bouts. L'un va dans DTO et l'autre dans BLL. Mais après, tu mettrais quoi dans quelle partie toi ?

dans le premier article il parle des DTO et des POCO

si tu veux faire du DTO une classe DTO(etudiant) est une classe qui n'a que:
les attributs (en private c mieux) (String _nom, String _prenom)
getter/setter (property Nom, Prenom)
les constructeurs (New(), New(Nom,Prenom)

La tu es plutot entrain de faire du POCO, c'est une autre architecture tout a fait valable

dans le projet dll dto:
un fichier Groupe

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
Public Class Groupe
 
    Public Property Id As Integer
 
    Private _Ordre As Integer
    Public Property Ordre As Integer
        Get
            Return _Ordre
        End Get
        Set(value As Integer)
            _Ordre = value
            Me.Status = e_status.Updated
        End Set
    End Property
 
    Private _textes As Textes
    Public Property Textes As Textes
        Set(value As Textes)
            _textes = value
            Me.Status = e_status.Updated
        End Set
        Get
            Return _textes
        End Get
    End Property
 
    Private _Comptetences As List(Of Competence)
    Public Property Competences As List(Of Competence)
        Get
            Return _Comptetences
        End Get
        Set(value As List(Of Competence))
            _Comptetences = value
            Me.Status = e_status.Updated
        End Set
    End Property
 
    Public Sub New(ByVal id As Integer, ByVal textes As Textes)
        Me.Id = id
        Me.Textes = textes
    End Sub
 
    Public Sub New(ByVal textes As Textes)
        Me.Id = 0
        Me.Textes = textes
    End Sub

un autre fichier e_status, je m'inspirait de RowState voir j'utiliserai celui-ci. Et si celui-ci est utile à la DTO, je ferai une class DTOBase qui a cet enum dans ses attributs et je ferai dérivé tous mes autres objets de DTOBase
(ps c'est toujours utile de faire une DTOBase et une BLLBase, DALBase car tu aura souvent des trucs en commun entre tout tes objets

Code:

1
2
3
4
5
Public Enum e_status As Integer
        UpToDate = 1
        Created = 2
        Updated = 3
    End Enum

dans la dll BLL un fichier BLLGroupe

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
Public BLLGroupe
 
    Public Shared Function NewGroupe(ByVal groupe As Groupe) As Boolean
        Return DAL_Groupe.NewGroupe(groupe)
    End Function
 
    Public Shared Function DeleteGroupe(ByVal groupe As Groupe) As Boolean
        Return DAL_Groupe.DeleteGroupe(groupe)
    End Function
 
    Public Shared Function UpdateGroupe(ByVal groupe As Groupe) As Boolean
        Return DAL_Groupe.UpdateGroupe(groupe)
    End Function
 
    Public Shared Function GetGroupeById(ByVal id As Integer) As Groupe
        Return DAL_Groupe.GetGroupeById(id)
    End Function
End Class

la BLL aura surement besoin de passer la chiane de connection à la DAL

ps: je n'ai pas vu l'utilité de la List

21/12/2011, 16h35
Kropernic

Et tu laisserais tomber la classes Groupes alors ?

Et pour ce qui est de l'implementation de INotifyPropertyChanged, tu places cela où ?

Est-ce encore nécessaire ?

C'est quand même chaud à bien prendre en main ce machin...

Je vais finir par regrette Cobol :aie:

J'espère juste que une fois que je le maitriserai, ça me permettra de gagner du temps.
21/12/2011, 16h43
BenoitM

Citation:

Et tu laisserais tomber la classes Groupes alors ?

Euh non je l'ai mis une partie en Dto.Groupe.vb et l'autre partie dans BLL.BLLGroupe

Citation:

Et pour ce qui est de l'implémentation de INotifyPropertyChanged, tu places cela où ??
Est-ce encore nécessaire ?

Tu fais du WPF?
C'est cool tu vas pouvoir apprendre une autre architecture :aie:

Citation:

C'est quand même chaud à bien prendre en main ce machin...

C'est juste une question d'habitude.
Le modèle en couche est assez simple.
sur celui de developpez.com tu as les sources se sera peut être plus facile à comprendre, un exemple est souvent mieux qu'un long discoure
21/12/2011, 16h45
Kropernic

Le WPF n'est pas du tout à l'ordre du jour (ouf !).

Bon, je vais creuser alors...

Ô joie, ô bonheur...
21/12/2011, 16h53
BenoitM

La logique du DTO (Data TRANSFERT Object) c'est de servire de passerelle entre tes différentes librairie et donc elles doivent être logiquement les plus lègere possible

Si tu as besoin de INotifyPropertyChanged alors on parlera plus d'une librairie Model qui sera partagée.
Car tu auras des informations utiles pour UI, la Validation ect...

Dans certains projets on crée un Model pour le client (ui) qui aurait justement ces validations et ses NotififyPropertyChange pour l'interface graphique et un DTO pour le serveur (webservice) mais ca fait souvent redondant mais du coté serveur tu n'auras pas tout le mécanisme des Notify qui sera enclencher.

Il y a du binding avec le Windows.Form aussi? :oops:
21/12/2011, 17h05
Kropernic

Ouais... les bindings, c'est encore assez flou aussi pour moi ^^.

C'est justement pour ça que j'ai le INotifyPropertyChanged.

Car j'affectais une liste d'objet en datasource d'un datagridview et ça ne prenait pas encore les ajouts d'objets à la liste.

Du coup, j'avais implémenter cette interface sur les conseils de mabrouki pour les ajouts soient pris en compte.

DONC (!), résumons...

GUI : Interface graphique avec les controles du genre keypress.

BLL : Classes qui créent les objets de la couche DTO et les repassent à la couche GUI et DAO. Ces classes ne sont jamais instanciées (toutes les méthodes en shared).

DAL : Classes qui envoient les données vers la db et qui récupère depuis la db. Ces classes ne sont jamais instanciées non plus (toutes les méthodes en shared).

DTO : Les classes d'objets métiers avec leurs méthodes de validation (genre le nom d'un client doit être d'au maximum 100 caractères et non null)

C'est juste ? *croise les doigts*

Pour finir, est-ce vraiment utile de créer une classe DTO.Groupes qui a comme propriété Groupe de type List(Of DTO.Groupe) ou est-ce que ça suffit d'utiliser directement la liste dans la GUI/DAL ? (je devine que ça dépend de l'usage qu'on en fait :aie:)

Griftou.
21/12/2011, 17h28
BenoitM
LA BLL peut faire des choses plus complexes.
Exemple
Code:

1 2 3 4 5 6 7 BLLCommander(Commande) { startTransaction() dal.AddCommande(Commande) dal.UpdateStock(Commande) CommitTransaction() }
ou des validations
Code:

1 2 3 4 5 BLLCommander(Commande) { if(Not dal.CheckStock(Commande)) throw Execption("plus assez de stock") ... }
Citation:

DTO : Les classes d'objets métiers avec leurs méthodes de validation (genre le nom d'un client doit être d'au maximum 100 caractères et non null)

Ce genre de validation peuvent être misent à plusieurs endroits
1) Dans le Model pour une plus grande réactivité. Tu peux afficher des messages dans UI dès qu'on tappe un nom depasse X caractère si le champ est vide
2) Dans la DAL parce que la limite n'a de sens que pour la base de donnée
3) Dans la BLL parce que c'est la qu'on trouve les validations métier.
Verifier que le nom n'est pas null est plutot une règle métier part contre la taille d'un champ est plutot une règle technique

Moi perso, je mettrai dans la DTO + une méthode CheckRecordValidity() qui sera appeler avant de faire des mis-à-jour des records

Mais les DTO ne vérifie que leurs propres états. En général elle ne vérifie pas si la commande est possible (cf exemple du stock suffisant)
21/12/2011, 17h34
Kropernic

En y repensant, les méthodes de validation que j'attribue à la couche DTO dans mon message précédent ne devraient-elles pas se trouver dans la couche BLL ?

Je pense que cela fonctionnera aussi bien d'un côté que de l'autre mais j'essaie de respecter la philosophie de la chose...
21/12/2011, 17h35
BenoitM

Citation:

Pour finir, est-ce vraiment utile de créer une classe DTO.Groupes qui a comme propriété Groupe de type List(Of DTO.Groupe) ou est-ce que ça suffit d'utiliser directement la liste dans la GUI/DAL ? (je devine que ça dépend de l'usage qu'on en fait )

Euh je crois qu'il faut utilise ObservableCollection<Group> plutot :)
21/12/2011, 17h38
Kropernic

Citation:

Envoyé par BenoitM

Euh je crois qu'il faut utilise ObservableCollection<Group> plutot :)

:aie: J'en avais encore jamais entendu parler...

Pfiou, j'aurais jamais fait autant tourner google qu'aujourd'hui !!!!

Ok, ça m'a l'air pas mal du tout ce machin. C'est en fait une liste qui implémente déjà INotifyPropertyChanged :).

Par contre, dans ma classe Groupes, j'avais overriddes la méthode Find. Je la fait où cette surcharge du coup ?:aie:
21/12/2011, 17h39
BenoitM

Citation:

Envoyé par griftou

En y repensant, les méthodes de validation que j'attribue à la couche DTO dans mon message précédent ne devraient-elles pas se trouver dans la couche BLL ?

Je pense que cela fonctionnera aussi bien d'un côté que de l'autre mais j'essaie de respecter la philosophie de la chose...

Je suis pas un expert en philo mais je pense que les 3 raisonements peuvent se justifier...

Et puis bon la philo c'est bien mais parfois faut rester pratique ;)

Peut-être attendre un avis des experts du forum ;)
21/12/2011, 18h22
Kropernic

Citation:

Envoyé par BenoitM

Je suis pas un expert en philo mais je pense que les 3 raisonements peuvent se justifier...

Et puis bon la philo c'est bien mais parfois faut rester pratique ;)

Tout à fait d'accord mais bon, j'aime bien être très rigoureux.

Citation:

Envoyé par BenoitM

Peut-être attendre un avis des experts du forum ;)

Cette discussion ne semble pas les intéresser. Où alors ils sont tous sur les voies ferrées avec les cheminots et c'est pour cela qu'ils ne répondent pas :mrgreen:

Bon, je suis en train de faire des tests avec ObservableCollections(Of T).

Ca m'a l'air cool mais comment je récupère un objet de la collection sur base de l'id de l'objet ? ^^
22/12/2011, 08h44
BenoitM

beuh généralement ta collection est binding a un controle (datagrid,combobox) ou sinon tu peux faire myColection.Single(etudiant=> etudiant.Id = 1)