Discussion :

[Kropernic]

Hello,

Après lecture de la traduction de l'article de Rudy Lacovara par Skalp, j'ai donc allégé mes DTO's (qui donc n'étaient pas de vrais DTO's) et je passe maintenant des POCO's à la couche GUI.

Un exemple vite faite d'un DTO et de son POCO :

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
 
Public Class PersonDTO
    Public Property Lastname as String
    Public Property Firstname as String
    Public Property Birthdate as Datetime
 
    Public Sub New()
    End Sub
End Class
 
Public Class PersonPOCO
    Public Property DTO as PersonDTO
 
    Public Sub New(dto as PersonDTO)
        Me.DTO = dto
    End Sub
 
    'et ici viennent les appels aux méthodes de persistances 
    'et autres méthodes/fonctions utilitaires.
End Class

Ma GUI reçoit donc la classe PersonPOCO. Avant, quand elle recevait PersonDTO, pas de souci pour afficher la liste dans un DataGridView. Je mettais une liste en datasource et j'ajoutais les colonnes moi-même en spécifiant pour chacune d'elle la propriété à afficher à l'aide de la propriété DataPropertyName (de type string) de la classe DataGridViewColumn.

Comment faire cela avec un POCO ?

Si je passe une liste de PersonPOCO en DataSource, le DataGridView ne contiendra qu'une seule colonne avec DTO comme header et PersonDTO comme contenu à chaque ligne.

Y a-t-il une solution en continuant à utiliser les POCO's ? (je pourrais parfaitement avant d'afficher, prendre le dto de chaque poco et en faire une liste pour la filer au DGV mais bon...)

[tomlev]

Tu pourrais créer des propriétés comme ça :

Code :

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

1
2
3
4
5
6
7
public string Name
{
    get { return DTO.Name; }
    set { DTO.Name = value; }
}
 
// etc...

[Kropernic]

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.

[rv26t]

Bonjour,

En utilisant le principe des DTO, vous devez passer entre les couches seulement des DTOs (seul ou sous forme de liste). Dans votre cas vous commettez une erreur de conception (seulement par rapport au principe des DTO, soyons bien daccord ) en voulant passer des POCOs à la place des DTOs.
Si vous passez des POCOs cela fonctionnera bien, mais comme vous le soulignez, en cas de modif cela a plus d'impact.

A mon avis, vous pouvez utiliser une liste de DTO en propriété dans votre POCO, Ainsi vous transmettez simplement la liste entre les couches. Le POCO pouvant gérer un ou plusieurs DTO dans sa liste des DTO.

Les méthodes utilisées dans le POCO peuvent recevoir des liste de DTO en paramètre ou retourner une liste de DTO suivant les besoins.

[Kropernic]

Bonjour,

En utilisant le principe des DTO, vous devez passer entre les couches seulement des DTOs (seul ou sous forme de liste). Dans votre cas vous commettez une erreur de conception (seulement par rapport au principe des DTO, soyons bien daccord ) en voulant passer des POCOs à la place des DTOs.
Si vous passez des POCOs cela fonctionnera bien, mais comme vous le soulignez, en cas de modif cela a plus d'impact.

A mon avis, vous pouvez utiliser une liste de DTO en propriété dans votre POCO, Ainsi vous transmettez simplement la liste entre les couches. Le POCO pouvant gérer un ou plusieurs DTO dans sa liste des DTO.

Les méthodes utilisées dans le POCO peuvent recevoir des liste de DTO en paramètre ou retourner une liste de DTO suivant les besoins.

A mon avis, il doit y avoir un truc sur lequel je n'ai pas encore percuté.

Je vais essayer de résumé ma façon de voir les choses.
Avant l'article :

• 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 DTO ou une liste de DTO.

Et du coup, il m'arrivait de fourrer quand même une ou deux méthodes dans mes DTO histoire de les avoir sous la main.


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 ?


EDIT :
Une idée en l'air... Et si, plutôt que de contenir un DTO, un POCO héritait d'un DTO ? J'aurais accès directement aux propriétés dans cas et n'aurai pas le travail en double en cas d'évolution du modèle.
Est-ce une bonne idée ? (quelqu'un aurait un bon bouquin d'archi à conseiller ?)

[rv26t]

• 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 DTO ou une liste de DTO.

Et du coup, il m'arrivait de fourrer quand même une ou deux méthodes dans mes DTO histoire de les avoir sous la main.

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)

La manipulation des DTOs étant éclairçie. Il y a un autre point sur les POCO.



Pour aller plus loin et comme indiqué sur cet article
Quelle est la différence entre un DTO et un POCO ?
le POCO ne contient pas de méthodes concernant la persistance.

Code :

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

1
2
3
4
5
6
7
8
9
10
Public Class PersonPOCO
    Public Property DTO as PersonDTO

    Public Sub New(dto as PersonDTO)
        Me.DTO = dto
    End Sub

    'et ici viennent les appels aux méthodes de persistances (Erreur ici , un POCO ne contient pas de logique de persistance)
    'et autres méthodes/fonctions utilitaires.
End Class

Dans la BLL il existe donc une partie (une un ou des classes) qui s'occupe de la liaison avec la DAL et qui utilise les POCO.
C'est là qu'il faut bien réfléchir à la base entre les relations qui existe entre les différente couches (concernant les DTOs) ainsi que la structuration interne de la couche BLL (POCO et manipulation pour la DAL et l'UI).

Sinon vous pouvez aussi ne pas utiliser cette partie séparation POCO et persistance. Mais il est vrai qu'avec ce principe vous séparez bien les diverses fonctionalités d'une application.

C'est un principe qui, je pense, une fois assimilé est assez pratique d'utilisation, et rend la maintenance plus aisée puisque les fonctionalités sont bien séparées.

[Kropernic]

Ok donc un Poco, c'est une usine à DTO.

Toutes les méthodes d'un poco sont shared (static en C#) alors ? Je ne vois pas l'intérêt d'instancier un objet qui n'est utilisé que via ses méthodes et fonctions.

Sinon j'ai testé en modifiant 2 de mes Poco's actuels (qui contiennent donc un dto) en les faisant héritant du dto et ça marche pas mal en fait. Maintenant, question perf, j'ignore les conséquences mais bon, je ne bosse pas pour la nasa non plus .

Bref, dès que j'ai la confirmation de mon premier paragraphe, je m’attèle à la tâche.

[rv26t]

Toutes les méthodes d'un poco sont shared (static en C#) alors ? Je ne vois pas l'intérêt d'instancier un objet qui n'est utilisé que via ses méthodes et fonctions.

Là, c'est plus une question générale vis à vis de la POO.
Dans la DAL c'est pareil. Les données ne font que transiter pour être lues ou enregistrées.
On cré un objet le temps de son utilisation, puis on le détruit. Certain dure plus longtemps que d'autre, voire même le temps de l'application tous dépend des besoins.

On a un décalage dans les questions réponses.
Mais je ne sais pas tout non plus , Hein.

[Kropernic]

Full shared ce sera alors.

Du coup... Pourquoi ne pas utiliser directement un module ? (bon là j'ai fait mes classes, j'vais garder mes classes hein ^^)

Je vais p-e dire une connerie mais, en C#, on peut déclarer des classes static non ?

En VB, pas moyen de déclarer une classe shared . Ils ont fait les modules à la place '-_-.

Et surtout, à quoi sert la propriété dto du poco de l'article ? Je n'en vois vraiment pas l'intéret... :-/

[rv26t]

J'ai pas le temps de répondre à vos questions qu'il y en a d'autres

Full shared ce sera alors.

Du coup... Pourquoi ne pas utiliser directement un module ? (bon là j'ai fait mes classes, j'vais garder mes classes hein ^^)

Pour la raison que j'indique dans le post précédant.
En poo on garde l'objet en mémoire avec ses méthodes de manip. (Dans la BLL) le temps de son utilisation.
Un peu comme lorsque vous utilisiez les DataSets. Vous pouvez faire le lien avec la liste DTO qui est en propriété dans votre POCO dans la BLL.

Je vais p-e dire une connerie mais, en C#, on peut déclarer des classes static non ?

En VB, pas moyen de déclarer une classe shared . Ils ont fait les modules à la place '-_-.

On fait une classe et on déclare les méthodes en shared.
Mais il vaut mieux garder le principe de l'objet on l'on cré ce dont a besoin et pour une durée de vie déterminée.

Et surtout, à quoi sert la propriété dto du poco de l'article ? Je n'en vois vraiment pas l'intéret... :-/

Préciser l'article, il faut que je le regarde pour être sur de bien répondre à votre question.
[Edit]Vous pouvez faire le lien avec la liste DTO qui est en propriété dans votre POCO dans la BLL dans votre UI. (puisque le DTO renplace le DataSet)[/Edit]
Après, je ne sais pas tout non plus, par rapport à toutes vos questions.
Il serait interressant d'avoir d'autres avis et regard sur le sujet.

Bon , je reviendrais un peu plus tard.

[rv26t]

Votre édit est passé pendant que j'écrivais.
Pour répondre à votre question, cela ne change rien.
Que vous héritiez des DTO ou que vous ayez une propriété DTO si vous évoluez et changez la structure du DTO la modif sera répercutée par l'héritage ou le type DTO. Il faudra en tout état de cause rajouter les manip pour la(les) nouvelle(s) donnée(s) ajoutée(s) dans le DTO.

Il me semble que le type DTO est mieux, car si l'on utilise une liste de DTO comme propriété, cela me semble plus compliqué à faire avec l'héritage (pour avoir seulement les données en forme de liste).

[Kropernic]

Y a quand même toujours un truc qui me chipote.

GUI consomme les méthodes de BLL (POCO) et reçoit un (ou plusieurs) DTO.

A quoi ça sert que le POCO ait une propriété DTO ? Juste avec les méthodes/fonctions de manipulation des DTO ça suffit non ? Il reçoit un dto (ou autre) en input et produit un dto en output (ou modifie celui qu'il a reçu en input si on le passe par référence).

Du coup, j'ai une classe qui ne contient que des méthodes. En soit, ça ne me gêne pas, c'est au final ce que je faisais avant d'avoir lu la traduction de skalp. Mais du coup, je ne comprends plus du tout l'intérêt de l'article

[rv26t]

Y a quand même toujours un truc qui me chipote.

GUI consomme les méthodes de BLL (POCO) et reçoit un (ou plusieurs) DTO.

A quoi ça sert que le POCO ait une propriété DTO ? Juste avec les méthodes/fonctions de manipulation des DTO ça suffit non ? Il reçoit un dto (ou autre) en input et produit un dto en output (ou modifie celui qu'il a reçu en input si on le passe par référence).

Effectivement certaines méthodes n'ont pas besoin de manipuler la propriété DTO. J'en avais déjà parlé dans une autre discution avec vous, ou je donnais des exemples. ( par exemple un total, une moyenne, ...) La méthode reçoit un DTO et renvoie une valeur.
Mais parfois on peut avoir besoin de garder en mémoire les données. Cas ou l'utilisateur à plusieurs étapes à franchir avant de valider l'ensemble des données. Les données peuvent être conservées dans le POCO, jusqu'a ce que toutes les manip soient faites et validées.
(exemple , pas forcément adapté à ce que vous faite, commande sur internet, choix de différents articles, validation des choix, préparation payment, ... sur différent écran avec différentes fonctionnalitées.)
C'est un peu simplifié, mais c'est pour vous montrer le principe.