Discussion :

[Sankasssss]

Bonjour à vous tous,

cela fait un bout de temps que je lis les différentes discussions sur l'utilisation de POCO - DTO.

J'ai bien lu les différents articles provenant de cette discussion :

En fait c'est partie de ces tutos
- High Performance Data Access Layer Architecture Part 1
- High Performance Data Access Layer Architecture Part 2
- High Performance Data Access Layer Architecture Part 3
et
Quelle est la différence entre un DTO et un POCO ?

Ma question provient de cette discussion, où il est dit :

Après l'article :
Vu que mettre des méthodes dans un DTO, c'est mal, je vais utiliser les objets de la couche BLL et faire un POCO.
Du coup, ça donne :

• Un DTO est un conteneur le plus léger possible et à ce titre, il ne contient que des propriétés et un constructeur.
• La couche BLL consomme les méthodes de la couche DAL et reçoit en retour un DTO ou une liste de DTO.
• La couche GUI consomme les méthodes de la couche BLL et reçoit en retour un POCO ou une liste de POCO.

Où est-ce que je me plante ?

Sur le 3ème point.

La couche GUI consomme les méthodes de la couche BLL et reçoit en retour un DTO ou une liste de DTO. Seul le DTO transite entre les couches.


Même si vous avez un POCO dans votre BLL vous ne transmettez que le DTO.
Le POCO est une classe de votre BLL qui contiend un DTO (ou liste de DTO) et les méthodes qui les manipules. (Le POCO s'occupe de la partie logique métier uniquement, quand il a fait son travail, il renvoie le DTO)

Mais j'ai du mal à comprendre, si mon POCO est l'objet métier qui contient toutes les méthodes métiers et que seul mon DTO doit passer dans les différentes couches. Comment peut-on interagir sur le DTO via la GUI ?

Moi j'aurais stocké le POCO dans la GUI pour pouvoir appeler les différentes méthodes de mon POCO dans celle-ci.

Bref je me perd, comme beaucoup visiblement sur la notion de POCO vs DTO et leurs utilisations

[Kropernic]

Avec le recul, après avoir relu quelques fois les articles (si j'ai bien compris), je réalise qu'en fait un POCO n'est sensé servir qu'à la validation des données.

Dans la BLL, il devrait donc en théorie y avoir encore un (ou plusieurs?) autre type d'objet à côté des POCO pour s'occuper du reste.

Séparation que personnellement je passe à la trappe. Sur un très gros projet, je peux éventuellement envisagé l'utilité mais de mon côté, j'ai un objet BLL qui contient les méthodes de validation, les méthodes de persistances, les méthodes utilitaires, etc. .

Voilà par exemple, une classe de la couche BLL du projet que je suis en train de développer :

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
Public Class Opening
    Public Property DTO As POP_DTO.Opening
 
    Public Sub Save()
        POP_DAL.Opening.Save(Me.DTO)
    End Sub
 
    Public Sub Delete()
        POP_DAL.Opening.Delete(Me.DTO)
    End Sub
 
End Class
 
Public Class Openings
    Public Property DTO As List(Of POP_DTO.Opening)
 
    Public Sub New()
        Me.DTO = New List(Of POP_DTO.Opening)
    End Sub
 
    Public Shared Function FetchAll(str_id As Byte, Optional year As Short = -1) As Openings
        If year = -1 Then
            year = Today.Year
        End If
 
        Dim ops As New Openings
        For Each d As POP_DTO.Opening In POP_DAL.Opening.GetAll(str_id, year)
            ops.DTO.Add(d)
        Next
        Return ops
    End Function
 
    Public Shared Function FetchByDates(str_id As Byte, debut As DateTime, Optional year As Short = -1) As Openings
        If year = -1 Then
            year = Today.Year
        End If
 
        Dim ops As New Openings
        For Each d As POP_DTO.Opening In POP_DAL.Opening.GetByDates(str_id, year, debut)
            ops.DTO.Add(d)
        Next
        Return ops
    End Function
 
    Public Shared Function FetchByWeek(str_id As Byte, week As Byte, Optional year As Short = -1) As Openings
        If year = -1 Then
            year = Today.Year
        End If
 
        Dim ops As New Openings
        For Each d As POP_DTO.Opening In POP_DAL.Opening.GetByWeek(str_id, year, week)
            ops.DTO.Add(d)
        Next
        Return ops
    End Function
 
    Public Function GetById(id As Integer) As Opening
        If (From o As POP_DTO.Opening In Me.DTO
            Where o.Id = id
            Select o).Count > 0 Then
            Dim op As New Opening
            op.DTO = (From o As POP_DTO.Opening In Me.DTO
                        Where o.Id = id
                        Select o).First
            Return op
        Else
            Return Nothing
        End If
    End Function
 
    Public Function GetByDate(d As DateTime) As Opening
        If (From o As POP_DTO.Opening In Me.DTO
            Where o.Debut.Date = d.Date
            Select o).Count > 0 Then
            Dim op As New Opening
            op.DTO = (From o As POP_DTO.Opening In Me.DTO
                        Where o.Debut.Date = d.Date
                        Select o).First
            Return op
        Else
            Return Nothing
        End If
    End Function
 
    Public Function GetByDay(d As System.DayOfWeek) As Opening
        If (From o As POP_DTO.Opening In Me.DTO
             Where o.Debut.DayOfWeek = d
             Select o).Count > 0 Then
            Dim op As New Opening
            op.DTO = (From o As POP_DTO.Opening In Me.DTO
                        Where o.Debut.DayOfWeek = d
                        Select o).First
            Return op
        Else
            Return Nothing
        End If
    End Function
End Class

N.B. : Je dois encore ajouter une méthode Save() et Delete() dans la classe Openings mais elle ne fera qu'appeler en boucle les méthodes correpondante dans la classe Opening à priori. Ca m'évitera d'avoir 2 procédures stockées différentes au niveau de la DB (une recevant un seul objet et une recevant recevant une liste d'objet).

Bref, une classe au singulier qui contient un (seul) DTO et les méthodes de persistance vers la DB (ici il n'y a pas de méthodes utilitaire mais il pourrait y en avoir). Et une classe au pluriel qui contient une liste de DTO's, les méthodes de récupération depuis la DB et des méthodes utilitaire pour sélectionner un DTO précis de la liste.

J'espère que ça aide :-/

[Sankasssss]

A force de relire ce poste je me dis qu'en réalité rien n'interdit de stocker un POCO dans la GUI du moment qu'on ne le fait pas transiter d'une couche à une autre...
Je suis dans le bon?

EDIT : On a posté en même temps, je lis ta réponse

[Kropernic]

J'ai oublié de préciser...

Au final, ma couche GUI instancie des objets de la couche BLL et utilise leur propriété DTO pour passer les données à afficher aux composants visuels.

[Sankasssss]

Merci pour tes interventions.

J'ai bien compris ton nouveau modèle de donnée.

...mais de mon côté, j'ai un objet BLL qui contient les méthodes de validation, les méthodes de persistances, les méthodes utilitaires, etc.

C'est justement ça qui me gène personnellement, c'est d'avoir les méthodes/variables métier en dehors de mon DTO car tout l'avantage d'avoir une collection d'objet POCO serait d'avoir aussi accès à la logique métier.

J'ai vraiment du mal à m'exprimer sur ce nouveau sujet mais en gros j'ai du mal à comprendre l'avantage de séparer autant les couches métier car cela oblige à tout coder 2 fois.
Suivant cet article : Quelle est la différence entre un DTO et un POCO ?

Je devrais faire un objet PersonRepository qui me retournerait des POCO person mais donc aurait les mêmes méthodes que ma couche DAL comme GetColPersonsByAge mais ces dernières méthodes ne serait qu'une surcharge qui bouclerait sur la collection de DTO pour en faire une collection de POCO. Du coup je me retrouve avec deux énumérations de collection juste pour séparer l'accès au donnée de la logique métier.
Et au final je ne manipulerais que des POCO car c'est principalement dont j'ai besoin dans l'application pour valider les données, les transformées et les décorer.

Cela oblige aussi dans le POCO de recoder toutes les propriétés du DTO pour y avoir accès directement comme dans la réponse de tomlev dans une de tes discussions ce que je trouve très peu pratique comme toi.

C'est pas faux.

J'espérais juste pouvoir m'en passer car si mon modèle évolue, je devrai alors faire les modifs à 2 endroits. Une fois dans DTO et une fois dans BLL. C'est un peu dommage je trouve.

Dans l'article il est dit :

Pourquoi devrais-je faire tout ça ?
Mais, je pense que la plupart des développeurs. NET seront amenés à utiliser des POCO et des Repositories (mais pas de DTO) via les ORM (NDT : mapping objet-relationnel). Entity Framework, NHibernate, et beaucoup de ces ORM exigent ou partent du principe que l'architecture est de type POCO.

Du coup j'ai fortement envie de fusionner le repository et le DAL ainsi que le POCO et le DTO.

J'avoue être complétement largué sur l'avantage d'autant de séparation.

Si ma DAL me renvoyait directement mon POCO, plus besoin de repository.

[DotNetMatt]

Ce sujet fait couler beaucoup d'encre ! Il n'y a pas de réponse toute tranchée.

Effectivement dans certains cas, comme l'utilisation d'un ORM, on part du principe que derrière on utilise des POCO. Les DTO étant utilisés conjointement avec une DAL ordinale classique.

Le fait d'avoir DAL + DTO + POCO double effectivement le travail puisqu'il faut coder 2 fois les mêmes propriété. Une alternative serait de dériver les POCO des DTO. Ainsi, le POCO expose les propriétés du DTO et lui ajoute la validation. On a également accès aux méthodes de persistence du DTO. Mais dans ce cas, on se retrouve dans une situation hybride.

L'avantage de séparer les DTO et les POCO peut s'expliquer notament parce que d'un point de vue "logique", on a effectivement besoin de valider les données avant de les persister. Le fait d'avoir le cheminement suivant :
UI --> Business --> POCO --> DTO --> DAL
oblige à passer par la validation (POCO) et donc de déclencher une exception en amont de toute opération de persistence.

Si on fusionne la couche POCO et la couche DTO, il faut s'obliger à appeler la/les méthodes de validation avant de persister les objets. C'est un peu comme si on était un peu plus "laxiste" vis à vis de la validation, car si demain un développeur oublie d'appeler la/les méthodes, il pourra persister des données potentiellement erronnées... Pour éviter cela on peut imaginer implémenter une interface (IValidation) par exemple qui serait appelée par le Business avant de passer à la main à la couche fusionnnée POCO/DTO.

Il faut également considérer que sur des projets manipulant des objets complexes, il peut être utile de séparer la couche POCO de la couche DTO afin de s'y retrouver un peu plus facilement, et d'isoler la validation du reste. Mais sur des projets plus simples ça peut rajouter une couche pour pas grand chose.

[Kropernic]

Tout le monde semble d'accord pour dire qu'un POCO ne sert qu'à la validation.

Voici mon approche (mais cela tient peut-être du fait que j'ai les 2 casquettes là où je bosse) :

Pourquoi m'embêter (pour rester poli) à valider les données avant de les envoyer vers la DB car de toute façon, si une donnée n'est pas valide, elle sera rejetée par la DB. Autant alors traité l'erreur retournée (cad informer l'utilisateur que la donnée X n'est pas bonne) et puis voilà.

Pour ma part, s'il y a besoin de valider les données dans l'applicatif, c'est que le DBA a mal fait son job derrière pour la DB.**
Personnellement, dans mes DB, je choisis les types de données adéquats et s'ils n'existent pas, je les fabrique.

Bête exemple tout simple (avec MSSQLSRV) :
Dernièrement, j'ai eu besoin de stocker dans une table un numéro de semaine. Non seulement j'utilise pour cette colonne le type tinyint afin de minimiser le stockage sur le disque mais en plus, je lui ajoute une contrainte check vérifiant que le nombre introduit est bien supérieur à 0 et inférieur à 54. De ce fait, plus besoin de valider le numéro de semaine encoder dans l'applicatif. La donnée en DB ne sera JAMAIS erronée.

**Je me rends compte en écrivant ces lignes que cela n'est vrai que pour les applications avec persistances dans un SGDBR ou équivalent. Si on persiste par exemple dans un fichier texte, ça pue un peu... Quoi que avec le XML, on peut définir un template (XLT je crois) pour définir le format et donc les contraintes de validation... Quid de type de persistance nécessitant réellement une validation applicative ?

[rv26t]

Bonjour,

Attention le DTO n'est pas une couche, c'est l'ensemble de données qui transite entre les couches.
Le but étant de transférer entre les couches un objet de données minimal (pour être performant, notement lors de la lecture en BDD)

Après la structure des couches applicatives n'a rien a voir avec les DTO.
Vous pouvez très bien définir la structure de vos couches applicatives suivant la taille et le complexité de votre projet. Puis utiliser les DTO (pour être performent) ou pas (pour rester plus simple).

@Kropernic

Tout le monde semble d'accord pour dire qu'un POCO ne sert qu'à la validation.

Et de toute autre logique métier.

Pourquoi m'embêter (pour rester poli) à valider les données avant de les envoyer vers la DB car de toute façon, si une donnée n'est pas valide, elle sera rejetée par la DB. Autant alors traité l'erreur retournée (cad informer l'utilisateur que la donnée X n'est pas bonne) et puis voilà.

Parceque là en terme de performance, ce n'est pas terrible.
[Edit]Déjà dit pendant que j'écrivais[/Edit]

@DotNetMat

Le fait d'avoir DAL + DTO + POCO double effectivement le travail puisqu'il faut coder 2 fois les mêmes propriété. Une alternative serait de dériver les POCO des DTO. Ainsi, le POCO expose les propriétés du DTO et lui ajoute la validation. On a également accès aux méthodes de persistence du DTO. Mais dans ce cas, on se retrouve dans une situation hybride.

L'avantage de séparer les DTO et les POCO peut s'expliquer notament parce que d'un point de vue "logique", on a effectivement besoin de valider les données avant de les persister. Le fait d'avoir le cheminement suivant :
UI --> Business --> POCO --> DTO --> DAL
oblige à passer par la validation (POCO) et donc de déclencher une exception en amont de toute opération de persistence.

Il me semble que vous avez mélangé les termes DTO et Repository, non ?

@Sankasssss
Ce qu'il faut percevoir dans l'article c'est que les DTO sont indépendant du reste.
Avec la programmation en couche (DAL<->BLL (qui peut être décomposé en POCO et Repository)<->UI), les DTO représente un ensemble de données qui transites entre elles (pour être performant).

Donc mon avis est d'utiliser les éléments dont on à besoin, comme le fait Kropernic.
Il faut prendre les avantages de ces principes, mais ne pas vouloir à tout prix coller à ceux-ci (au risque de se créer du travail pour rien).

Personnellement dans les DTO j'ai trouvé une solution pour ne pas utiliser forcément les outils plus conventionnels (dataset, etc) et travailler coté performance.
Mais je n'utilise pas la structure POCO et Repository parceque justement pour l'instant je n'ai que peu de manipulation métier.

[rv26t]

Je poste a nouveau,
Mon précédant message était général

ici je répond plus précisément à 2 remarques

Je devrais faire un objet PersonRepository qui me retournerait des POCO person mais donc aurait les mêmes méthodes que ma couche DAL comme GetColPersonsByAge mais ces dernières méthodes ne serait qu'une surcharge qui bouclerait sur la collection de DTO pour en faire une collection de POCO. Du coup je me retrouve avec deux énumérations de collection juste pour séparer l'accès au donnée de la logique métier.
Et au final je ne manipulerais que des POCO car c'est principalement dont j'ai besoin dans l'application pour valider les données, les transformées et les décorer.

Pour la lecture effectivement c'est juste un autre appel. (c'est aussi ce qui m'embète)
Pour l'enregistrement non
Ex : avec les tests que j'avais fait par rapport aux exemple des tutos.
Une DAL maison sous forme de DLL qui renvoie des DTO (avec des méthodes génériques).
La BLL

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
Public Class BLLPerson
    Private PersDb As PersonDB = New PersonDB
 
    Public Function LitPersonneEMail(ByVal eMail As String) As PersonDTO
        Return PersDb.GetPersonByEmail(eMail)
    End Function
 
    Public Function LitPersonnes() As List(Of DTOBase)
        Return PersDb.GetAll()
    End Function
 
    Public Sub EnregistrePersonne(ByVal dtop As PersonDTO, ByVal inserer As Boolean)
        ' validation données
 
        'enregistre
        PersDb.EnregPerson(dtop, inserer)
    End Sub
 
End Class

Une partie DAL application
La lecture

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Public Class PersonDB
    Inherits clsDALAppli
 
    Public Function GetPersonByEmail(ByVal email As String) As PersonDTO
        Const K_REQUETTE As String = "select * from personnes where email = ?"
        Try
            DALApp.AjouteParam("email", DbType.String, email)
            Return DALApp.GetSingleDTO(Of DTOParser_Person)(K_REQUETTE)
        Catch ex As Exception
            '...
        End Try
        Return Nothing
    End Function

L'enregistrement

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
    ' avec le DTO 1 seul paramètre
    Public Sub EnregPerson(ByVal UnePersonne As PersonDTO, ByVal Ins As Boolean)
        Const K_REQUETTE_INSERT As String = "insert into personnes ([PersonId], [City], [Email], [ImAddress], [ImType], [LanguageId], [NamePers], [NickName], [Password], [PhoneHome], [PhoneMobile], [State], [TimeZoneId], [UtcCreated], [UtcModified], [ZipCode], [SpeakFrench]) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) "
        Dim req As String = "update personnes set City=?, [Email]=?, [ImAddress]=?, [ImType]=?, [LanguageId]=?, [NamePers]=?, [NickName]=?, [Password]=?, [PhoneHome]=?, [PhoneMobile]=?, [State]=?, [TimeZoneId]=?, [UtcCreated]=?, [UtcModified]=?, [ZipCode]=?,SpeakFrench=? where PersonId = ?"
        Dim res As Integer
        If Ins Then req = K_REQUETTE_INSERT
        Try
            DALApp.EffaceListParam()
            If Ins Then DALApp.AjouteParam("PersonId", DbType.Int32, UnePersonne.PersonId)
            DALApp.AjouteParam("City", DbType.String, UnePersonne.City)
            DALApp.AjouteParam("Email", DbType.String, UnePersonne.Email)
            DALApp.AjouteParam("ImAddress", DbType.String, UnePersonne.ImAddress)
            DALApp.AjouteParam("ImType", DbType.Int32, UnePersonne.ImType)
            DALApp.AjouteParam("LanguageId", DbType.Int32, UnePersonne.LanguageId)
            DALApp.AjouteParam("NamePers", DbType.String, UnePersonne.NamePers)
            DALApp.AjouteParam("NickName", DbType.String, UnePersonne.NickName)
            DALApp.AjouteParam("Password", DbType.String, UnePersonne.Password)
            DALApp.AjouteParam("PhoneHome", DbType.String, UnePersonne.PhoneHome)
            DALApp.AjouteParam("PhoneMobile", DbType.String, UnePersonne.PhoneMobile)
            DALApp.AjouteParam("State", DbType.String, UnePersonne.State)
            DALApp.AjouteParam("TimeZoneId", DbType.Int32, UnePersonne.TimeZoneId)
            DALApp.AjouteParam("UtcCreated", DbType.Date, "20/05/2013")
            DALApp.AjouteParam("UtcModified", DbType.Date, "31/05/2013")
            DALApp.AjouteParam("ZipCode", DbType.Int32, 6)
            DALApp.AjouteParam("SpeakFrench", DbType.Boolean, True)
            If Not Ins Then DALApp.AjouteParam("PersonId", DbType.Int32, UnePersonne.PersonId)
 
            DALApp.ExecuterCommande(req, res)
        Catch ex As Exception
 
        End Try
 
    End Sub

Utilisation en UI
Lecture

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        Dim p As PersonDTO = Persbll.LitPersonneEMail("Email")

Cela oblige aussi dans le POCO de recoder toutes les propriétés du DTO pour y avoir accès directement comme dans la réponse de tomlev dans une de tes discussions ce que je trouve très peu pratique comme toi.

Non, les méthodes reçoivent ou renvoient des dtos, on peut les manipuler
On peut placer une propriété de type DTO dans le POCO, et on peut accéder aux propriétés internes du DTO.


En utilisant les exemple ci-dessus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
        Dim p As PersonDTO = Persbll.LitPersonneEMail("Email")
        MessageBox.Show(p.PersonId)

C'est une propriété du dto et je ne les ais pas redéfinies dans la BLL (ou POCO si je les avais utilisés).

un ensemble de dto et de propriétés de celui-ci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
        Dim ListPers As List(Of DTOBase)
        ListPers = Persbll.LitPersonnes()
        For Each UnePersonne As PersonDTO In ListPers
            MessageBox.Show(UnePersonne.NamePers & " " & UnePersonne.NickName & " " & UnePersonne.SpeakFrench)
        Next

Une mise à jour (par exemple celui lu auparavant)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
        p.City = "City"
        Persbll.EnregistrePersonne(p, False)

Par contre à partir du moment ou l'on veut modifier les données du DTO avant de les passer à l'UI là il faut redéfinir le nouvel objet de données. (le tuto n'aborde pas ce cas) Il reste très vague sur toute autre logique métier.