Discussion :

[Kropernic]

Hello,

Je reviens une fois de plus sur un sujet qui me tiens à coeur de comprendre, les DTO et leur utilisation.

Je ne link plus les différents articles qui existe mais pour rappel, il y a les traductions de rvt26 des article de Rudy Lavocara (j'écorche sûrement son nom) ainsi qu'un article de skalp (cela devrait suffir pour que les curieux qui ne les auraient pas encore lu puisse les trouver).

Il s'agit de travailler sur un projet multi-couche organisé comme suit :

• une couche DTO qui contient les objets de bases
• une couche DAL qui communique avec la DB (qui fait référence la couche DTO)
• une couche BLL qui communique avec la DAL au moyen de DTO (qui fait référence à DAL et DTO)
• une couche GUI qui communique avec la BLL au moyen de DTO (qui fait référence à BLL et DTO)

Voilà pour l'architecture...

Mon souci se situe dans la couche BLL.

Dans un précédent projet, je structurais une classe de la couche BLL comme suit :

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
 
Public Class BllClass
    Public Property DTO as DtoClass
 
    Public Sub New(dto as DtoClass)
        DTO = dto
    End Sub
 
    Public Shared Function GetFromDB(id as Integer) as BllClass
        Return New BllClass(DAL.DalClass.GetOne(id))
    End Function
 
    Public Sub Save()
        DAL.DalClass.Save(DTO)
    End Sub
End Class
Public Class BllClasses
    Public Property DTO as List(Of DtoClass)
 
    Public Sub New (dtos as List(Of DtoClass)
        DTO = dtos
    End Sub
 
    Public Shared Function GetFromDb(param as object) as BllClasses
        Return New BllClasses(DAL.DalClass.GetList(param))
    End Function
 
    Public Function GetOne(id as Integer) as BllClass
        Dim dto as DtoClass = (For d as DtoClass in Me.DTO
                                       Where d.Id = id
                                       Select d).FirstOrDefault
        Return New BllClass(dto)
    End Function
 
    Public Sub Save()
        For Each d as DtoClass in DTO
            DAL.DalClass.Save(d)
        End For
    End Sub
End Class

Avantage : Pas de duplication de code au niveau des propriétés des DTO. La couche GUI peut passer le DTO de l'objet BLL directement à un DataGridView par exemple.
Désavantage : 2 classes au lieu d'une. Une pour gérer un seul DTO et une pour gérer une liste.

J'ai brièvement réfléchi à comment éviter d'avoir cette duplication de classe et je suis arrivé à ceci :

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
 
Public Class BllClass
    Public Property Id as Integer
    Public Property P1 as Integer
    Public Property P2 as String
 
    Public Sub New(id as Integer, p1 as Integer, p2 as String)
        Me.Id = id
        Me.P1 = p1
        Me.P2 = p2
    End Sub
 
    Public Shared Function GetOneFromDb(id as Integer) as BllClass
        Dim dto as DtoClass = DAL.DalClass.GetOne(id)
        Return New BllClass(dto.Id, dto.P1, dto.P2)
    End Function
 
    Public Shared Function GetListFromDb(param as Object) as List(Of BllClass)
        Dim result as New List(Of BllClass)
        Dim dtos as List(Of DtoClass) = DAL.DalClass.GetList(param)
        For Each d as DtoClass in dtos
            result.Add(New BllClass(d.Id, d.P1, d.P2)
        End For
        Return result
    End Function
End Class

N.B. : Il manque un test ou l'autre mais l'idée est là...

Avantage : Une seule classe au lieu de deux.
Désavantage : Plus de code à écrire (il faut reproduire les propriétés du DTO dans BLL)

Mais avec ces solutions en 1 seule class, j'ai l'impression de perdre la philosophie des DTO's dans le sens que la couche GUI n'a même plus besoin de référencer la couche DTO puisqu'elle ne travaillera qu'avec les objets de la couche BLL et n'aura même pas conscience des DTO's sous-jacents. Pour afficher une liste dans un DataGridView, elle donnera une liste de BllClass et non pas une liste DtoClass.

Etant donné que je débute encore avec tout cela, je me tourne vers vous pour savoir quelle solution il faut préférer car cela a probablement des implications auxquelles je ne pense pas. Et je suis malheureusement sur un projet où je ne peux pas me permettre de perdre du temps à revenir en arrière à cause d'un souci auquel je n'aurais pas pensé causé par modélisation de la couche BLL... :-/

Vous faites comment vous ?

[DotNetMatt]

Dans l'absolu, tu dois rester sur le premier cas : le DTO est là pour voyager de couche en couche au travers de l'application, c'est son job. Ca simplifie également la maintenance car on regroupe à un endroit.

Désavantage : 2 classes au lieu d'une. Une pour gérer un seul DTO et une pour gérer une liste.

Effectivement ce n'est pas top, sauf s'il y a des besoins particuliers, comme par exemple pouvoir implémenter sa propre méthode Add pour ajouter des éléments à la liste et faire des vérifications en même temps... Mais rien ne t'empêche de caster ton BllClasses en tant que List(Of A) (son type de base) à la sortie de la BLL... Donc ce n'est pas forcément bloquant non plus.

Si ce post est lié à ton précédent post et au problème de faire une boucle, je pense que quoi qu'il advienne, tu vas devoir boucler : soit tu le fais dans ta classe BllClasses, soit tu le fais directement dans la DAL. Peu importe, à toi de choisir. Le plus simple de mon point de vue, c'est de le faire dans la DAL comme ça tu peux trimbaler des IEnumerables (ou autre) de DTO dans ton appli.

[Kropernic]

Cette discussion n'est pas du tout liée à une autre ;-)

Je vais donc rester dans la première situation. C'est bien ce qu'il me semblait. C'est plus proche de la philosophie des DTO et au final, c'est plus simple à gérer dans la couche GUI. Juste un type singulier et un pluriel.

Si d'autres personnes ont des avis et/ou méthodes d'utilisation différentes, ils sont plus que les bienvenus pour les exprimer.

[Kropernic]

Question corolaire : Dans la classe au plusieurs, est-ce judicieux d'utiliser une List(Of DtoClass) ?

Plus précisément, bien souvent à l'utilisation, celle liste va être passée en datasource d'un objet graphique. Or, il est recommandé d'utiliser des BindingList plutôt que des listes simples. On peut faire le cast de List vers BindingList sans souci ou bien il faut créé la bindinglist et ajouter les éléments un à un ?

[DotNetMatt]

L'intérêt des BindingList c'est surtout de faciliter la gestion du binding dans les deux sens (two-ways binding), notamment grâce à l'évènement ListChanged (porté par l'interface IBindingList) qui permet de détecter les changements et de rafraichir l'UI. Il faut voir ça comme un "wrapper" qui encapsule une liste typée... Donc ça restreint déjà les cas où il est réellement intéressant de les utiliser

Sinon pour passer d'une BindingList à une List, il suffit d'utiliser la méthode .ToList() de la BindingList.

[Kropernic]

L'intérêt des BindingList c'est surtout de faciliter la gestion du binding dans les deux sens (two-ways binding), notamment grâce à l'évènement ListChanged (porté par l'interface IBindingList) qui permet de détecter les changements et de rafraichir l'UI. Il faut voir ça comme un "wrapper" qui encapsule une liste typée... Donc ça restreint déjà les cas où il est réellement intéressant de les utiliser

Sinon pour passer d'une BindingList à une List, il suffit d'utiliser la méthode .ToList() de la BindingList.

BindingList permet surtout d'éviter des trucs débiles comme celle-ci XD