Utilisation d'une liste de POCO's comme datasource

**Kropernic** · 12/06/2013, 09h19

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** · 12/06/2013, 10h49

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** · 12/06/2013, 11h29

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** · 12/06/2013, 13h19

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** · 12/06/2013, 13h47

Envoyé par 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.

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** · 12/06/2013, 15h48

Envoyé par Kropernic

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.

Envoyé par Kropernic

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.

Envoyé par Kropernic

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.

Envoyé par Kropernic

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** · 12/06/2013, 15h58

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** · 12/06/2013, 16h02

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** · 12/06/2013, 16h06

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** · 12/06/2013, 16h15

Envoyé par Kropernic

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** · 12/06/2013, 16h18

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** · 12/06/2013, 16h26

Envoyé par 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).

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.

**rv26t** · 12/06/2013, 16h34

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

Envoyé par 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 ^^)

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.

Envoyé par Kropernic

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.

Envoyé par Kropernic

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** · 13/06/2013, 01h00

Mon post 6 donne déjà pas mal d'info.

Un POCO est un objet métier.
Comme beaucoup d'objet, il contient les données, et les méthodes qui manipulent ces données (logique de validation, logique métier).
Mais c'est effectivement un peu plus compliqué que cela, parce que parfois on a besoin des données furtivement (pour l'affichage simple, on va aller chercher les données suivant un critère, faire transiter celles-ci avec le DTO entre les couches, afficher, point final) mais c'est un cas particulier, et nous ne pouvons pas gérer sur des cas particulier.
(Dans un objet quelconque vous pouvez avoir un ensemble de propriétés qui définissent les données, mais à un moment donné, vous pouvez très bien ne manipuler qu'une partie de ces propriétés. Doit-on supprimer les autres ? non) Donc, ce n'est pas parce que certaines méthodes n'utilisent pas la propriété DTO qu'il faut la supprimer.

L'utilisation d'une propriété de type DTO est intéressante sur plusieurs points :

vous modifiez votre type DTO toutes les classes qui utilisent ce DTO sont automatiquement à jour, (pas besoin de toutes les reprendre pour rajouter les nouveautés en propriété) reste quand même à les gérer avec les méthodes.

Avec une propriété DTO vous affectez une seule propriété à votre POCO qui va pouvoir effectuer plusieurs manip différentes (validation de données, application des règles métier) qui sont des fonctionnalités (méthodes) différentes.

Sur une mise à jour, vous pouvez aussi garder la version d'origine issue de la base dans le POCO pendant la modif par l'utilisateur dans l'UI, s'il annule juste une partie de sa saisie, vous pouvez lui réafficher les données en l'état initial. (C'est un peu une cerise sur le gâteau)

Surtout, les méthodes dans votre POCO sont bien adaptées à la manipulation des données qui les concerne. Cela évite de s'éparpiller. Vous avez ainsi votre objet bien homogène. (Quitte à avoir quelques méthodes shared pour les cas simple)

Comme indiqué dans le tuto, répartition des tâches (fonctionnalités) plus unitaire. Pour la maintenance, les interventions peuvent être très ciblées.

Cas non traité dans le tuto, mais important à mon avis (voir ma remarque un peu plus loin)

avoir une propriété liste des DTO.

Il y a surement d'autres bonnes raisons.

_________________________________________________________________
Remarque
Il y a tout de même une incertitude qui subsiste par rapport au tuto. Et c'est peut être cela qui vous gène. [Edit](j'en parle d'ailleur dans mes posts précédants sans forcément détailler)[/Edit]

Il utilise une propriété simple DTO dans le POCO. Il me semble qu'une propriété de type liste DTO serait plus approprié. (voire les deux pour des manip plus simple, je ne sais pas)

Dans les cas simple, on n'utilise pas la propriété.

Dans le cas ou l'on ne manipule qu'une info, il n'y aura q'un seul élément dans la liste (pas génant, mais ça complexifie un peu)

Dans le cas ou l'on veut manipuler un ensemble d'info, la liste contiendra tout les éléments.

Dans certains cas ou pourra passer la liste à l'UI.

Dans le cas d'un lien DataSource sur une liste, je ne vois pas pourquoi on passerait cette liste à l'UI alors qu'il suffit de référencer cette liste DTO du POCO dans le DataSource. (on pourrait passer la liste DTO, bien sur)
En fin de manip de l'utilisateur le POCO fait son travail et transmet à la partie enregistrement.

Après, il y a peu être quelque chose qui m'échappe. (je n'utilisais pas les POCO, juste les DTOs) Je m'interroge sur cette partie. C'est là que vous ne retrouvez pas le principe de transmission DTO léger qui vous a induit en erreur.
[Edit]Autre possibilité, un POCO n'est peut-être pas l'objet approprié pour travailler avec des listes.[/Edit]

Tout cela représente une gymnaste importante. On est pas obligé d'utiliser ce principe des POCO au sein de la BLL. (Tout dépend de votre appli, et de votre approche) Mais ça reste à creuser tout de même.
Par contre les DTOs sont vraiment très intéressant à utiliser.

**Kropernic** · 13/06/2013, 08h16

Envoyé par rv26t

Après, il y a peu être quelque chose qui m'échappe. (je n'utilisais pas les POCO, juste les DTOs) Je m'interroge sur cette partie. C'est là que vous ne retrouvez pas le principe de transmission DTO léger qui vous a induit en erreur.
[Edit]Autre possibilité, un POCO n'est peut-être pas l'objet approprié pour travailler avec des listes.[/Edit]

A quoi ressemble votre BLL sans POCO alors ? N'ayant jamais eu aucun cours d'archi à l'école (même pas eu de cours de POO, c'est pour dire

), je n'ai découvert les DTO's que récemment et quand j'ai vu l'article de Skalp (différence entre POCO et DTO), j'ai cru qu'il fallait utilisé les POCO's dans la couche BLL si on utilise des DTO's. Je me suis probablement fourvoyé.

Quant aux méthodes/fonctions que je mettais dans mes DTO's avant (et que je suis tenté de remettre), je ne sais plus où les mettre

. Je parle de fonctions du genre ToString() histoire que mon objet s'affiche correctement s'il est passé comme source de donnée d'une colonne de DGV par exemple.

Envoyé par rv26t

Tout cela représente une gymnaste importante. On est pas obligé d'utiliser ce principe des POCO au sein de la BLL. (Tout dépend de votre appli, et de votre approche) Mais ça reste à creuser tout de même.
Par contre les DTOs sont vraiment très intéressant à utiliser.

C'est la conclusion à laquelle je suis arrivé également.

Je vais passer ce fil en résolu à présent.

**rv26t** · 13/06/2013, 12h44

J'ai peu de temps, mais

Envoyé par Kropernic

A quoi ressemble votre BLL sans POCO alors ? N'ayant jamais eu aucun cours d'archi à l'école (même pas eu de cours de POO, c'est pour dire

), je n'ai découvert les DTO's que récemment et quand j'ai vu l'article de Skalp (différence entre POCO et DTO), j'ai cru qu'il fallait utilisé les POCO's dans la couche BLL si on utilise des DTO's. Je me suis probablement fourvoyé.

J'utilise les DTO (propriétés + constructeur) sans POCO. Je fait transiter mes DTO ou liste de DTO entre mes couches.
L'utilisation des POCO n'est pas une obligation. C'est une solution complémentaire que l'on peut utiliser ou pas. (mais je faisais comme vous, j'étudiais le rpincipe)

Envoyé par Kropernic

Quant aux méthodes/fonctions que je mettais dans mes DTO's avant (et que je suis tenté de remettre), je ne sais plus où les mettre

. Je parle de fonctions du genre ToString() histoire que mon objet s'affiche correctement s'il est passé comme source de donnée d'une colonne de DGV par exemple.

Je dirai que celles-ci doivent être réparties dans les classes (par lesquelles le DTO transite) des différentes couches ou il est nécessaire qu'elles agissent sur le DTO.

Utilisation d'une liste de POCO's comme datasource

VB.NET

Discussions similaires

Partager

Partager