Discussion :

[DotNetMatt]

Si tu veux juste récupérer la propriété par son nom :

Code VB.NET :

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

Dim props As PropertyInfo() = p.GetType().GetProperties().Where(Function(p) p.Name = "PersonId").ToArray()

Si tu veux récupérer une propriété par son nom et si elle a l'attribut :

Code VB.NET :

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

1
2
3
4
5
6
7
Dim prop = GetType(TestDTO) _
                   .GetProperties() _
                   .Where(Function(p) _
                              p.GetCustomAttributes(GetType(TypePropertyAttribute), False) IsNot Nothing _
                              AndAlso p.Name = "PersonId") _
                    .Select(Function(p) p) _
                    .FirstOrDefault()

[rv26t]

J'ai mal posé ma question (désolé), en fait, je voudrai récupérer la valeur de l'attribut de la propriété PersonId. (je connais le nom "PersonId") Dans mon exemple la valeur de l'attribut de la propriété p.PersonId est : integer
Je souhaiterai le faire directement pas à travers une boucle (ou équivalent)

[DotNetMatt]

Je pense que quelque chose du genre devrait faire l'affaire :

Code VB.NET :

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

1
2
3
4
5
6
7
8
9
10
Dim prop = p.GetType() _
                   .GetProperties() _
                   .Where(Function(p) _
                              p.GetCustomAttributes(GetType(TypePropertyAttribute), False) IsNot Nothing _
                              AndAlso p.Name = "PersonId") _
                    .FirstOrDefault() _
					.GetCustomAttributes(GetType(TypePropertyAttribute), False) _
					.OfType(Of TypePropertyAttribute)() _
					.FirstOrDefault() _
					.GetTypeProperty()

Peut-être quelques ajustements à faire car j'ai réalisé la méthode en C#, puis converti en VB.NET à l'aide d'un outil...

[Kropernic]

Je suis un peu perdu là. Vous faites quoi avec ces attributs ?? Je pige pas trop :-/

Enfin faut dire que, à part mettre Serializable sur une classe parce que VS me disait qu'il fallait le faire, je ne les ai jamais utilisé ^^

[DotNetMatt]

Cela fait référence au Post n°13 de cette discussion :

Pour la validation au niveau de la BLL, il n'y a pas de solution miracle, si tu changes la longueur d'un champ en base, il faut répercuter ce changement dans le code. Il y a différentes façons de faire, soit à laide d'un genre de moteur de règles dans la BLL, soit en décorant simplement les propriétés des DTO avec des attributs, puis lors de la validation, analyser ces attributs et traiter en conséquence. Cette seconde solution est à mon sens la plus simple à gérer.

[Kropernic]

Cela fait référence au Post n°13 de cette discussion :

J'avais zappé ce passage. Merci ^^

[rv26t]

Merci DotNetMatt. Pas de problème j'adapte.

@Kropernic
Effectivement, le but est de récupérer le type de la propriété pour préparer la requête pour la BDD.

Mais pour le coup, cela me plait moyen pour 2 raisons :
1 - on utilise la réflexion.
2 - Quel que soit la façon de procéder on obtient pas directement la valeur.

[Edit]Kropernic, tu as déjà répondu pendant que j'écrivais

[Kropernic]

Merci DotNetMatt. Pas de problème j'adapte.

@Kropernic
Effectivement, le but est de récupérer le type de la propriété pour préparer la requête pour la BDD.

Mais pour le coup, cela me plait moyen pour 2 raisons :
1 - on utilise la réflexion.
2 - Quel que soit la façon de procéder on obtient pas directement la valeur.

[Edit]Kropernic, tu as déjà répondu pendant que j'écrivais

Pour préparer la requête ?

Cela aurait été pour indiquer par exemple la longueur max d'une donnée texte afin de valider la string qu'on reçoit, j'aurais compris. Mais pour préparer une requête ?? Ton type de données ne va tout de même pas changer si ?

[DotNetMatt]

Mais pour le coup, cela me plait moyen pour 2 raisons :
1 - on utilise la réflexion.
2 - Quel que soit la façon de procéder on obtient pas directement la valeur.

Effectivement, quelle que soit la méthode de validation choisir, il y aura des lourdeurs...

Microsoft a mis à jour ses best practices ici : Enterprise Library 6 – April 2013. Les reco pour la validation en utilisant le Validation Block sont dispo ici : 7 - Banishing Validation Complication: Using the Validation Application Block. Je vous invite à le lire car c'est très complet. On constate l'utilisation des attributs un peu partout

[EDIT]

Ton type de données ne va tout de même pas changer si ?

Le principe à appliquer en général, c'est qu'il faut tout valider et ne faire confiance à personne : ni à l'utilisateur, ni à la base de données, ni au développeur.

[BasicZX81]

Bonjour,
Tout ceci mets en évidence une contradiction intéressante. D'un coté on a le développement en couche qui doit permettre de faire sorte que si on modifie une couche cela n'impact pas les autres et d'un autre coté le besoin de faire communiquer les couches si je prends le cas précis ou on souhaiterais récupérer les valeurs de certains attributs issues de la BDD. (C'est ce que fait mon code dans un post un peu plus haut).
Contrairement a ce que j'avais dit j'ai laissé tombé l'idée de vouloir a tout prix séparer le code en couche pour cette raison là .
C'est ma façon de programmer et un choix que j'ai fait au début, mon programme ne nécessitant pas impérativement cette séparation.

[Kropernic]

Bonjour,
Tout ceci mets en évidence une contradiction intéressante. D'un coté on a le développement en couche qui doit permettre de faire sorte que si on modifie une couche cela n'impact pas les autres et d'un autre coté le besoin de faire communiquer les couches si je prends le cas précis ou on souhaiterais récupérer les valeurs de certains attributs issues de la BDD. (C'est ce que fait mon code dans un post un peu plus haut).
Contrairement a ce que j'avais dit j'ai laissé tombé l'idée de vouloir a tout prix séparer le code en couche pour cette raison là .
C'est ma façon de programmer et un choix que j'ai fait au début, mon programme ne nécessitant pas impérativement cette séparation.

Attention, si j'ai bien compris ton message, je crois que tu mélanges deux chose.

Si le modèle de données change de manière significative, bien sûr que les répercussion vont se faire sentir dans toutes les couches.
Par contre, si j'ai séparé mes couches, le jour où on décide de changer de SGDB, je n'ai que la DAL à réécrire . Et encore, qu'une partie de celle-ci (c'est un cas vécu personnellement). Pareil si d'une application winforms on veut en faire une application web. Bin on met de côté la couche GUI écrite en winform (VB ou C#) et on recommence avec de l'ASP.NET (enfin je crois, je n'ai jamais fait d'appli web).

[BasicZX81]

Oui j'ai répondu un peu vite.
(Je m'interresse au débat mais je suis débutant en même temps).

Si le modèle de données change de manière significative, bien sûr que les répercussion vont se faire sentir dans toutes les couches.

En effet c'est inévitable.
Je voulais dire que plutôt que de coder en dur mes attributs (longueurs de champs...etc) et à fortiori à plusieurs endroit du code, je fait en sorte de les obtenir depuis la BDD ou à un seul endroit (C'est une règle de programmation que je m'impose au maximum).
Je sais que c'est mon DTO qui contient cette information mais en réalité je ne sais pas encore très bien discerner le reste des couches de mon application. Il me semble que pour arriver à ce résultat mon DTO référence directement ce qui ressemble à une DAL.
Donc j'ai du faire une entorse aux règles du développement en couche pour arriver à ça et c'est pour ça que je parle de contradiction. Mais avec ma méthode si la longueur d'un champ de BDD est modifié il n'y a aucun impact sur le reste du code.

Après je ne dit pas que je me complique pas la vie pour rien

[DotNetMatt]

Au-delà du fait que tu te compliques un peu la vie en effet, c'est surtout que ça correspond à ton besoin actuel, mais il y a des cas où ça ne peut pas marcher.

Voici un exemple :
- via l'UI ASP.NET, utilisés par les clients externes, ton champ doit avoir une longueur max de X caractères.
- via l'UI WPF, utilisée par les clients internes, ton champ doit avoir une longueur max de Y caractères.
- les batch doivent insérer une valeur avec une longueur max de Z caractères.

Autre exemple, demain tu changes de SGBDR et celui-ci ne te permet pas de récupérer la taille des colonnes...

Tu auras probablement des difficultés à gérer ça en procédant tel que tu le fais Mais comme on l'a déjà dit, le principal c'est que ce que tu as fait réponde à ton besoin.

Il faut juste garder en tête que le fait de laisser le DTO porter les attributs de validation permet d'être plus flexible, sans dépendre de la base de données (voir ce qu'on peut faire avec le Validation Block de Microsoft par exemple) :
- Le DBA change la taille de la colonne ? Tu modifies ton attribut sur le DTO.
- Ton chef t'explique que pour l'UI WPF la taille à valider est différente ? Tu rajoutes un attribut sur le DTO.
etc. sans avoir à tout casser.

[BasicZX81]

Merci pour la réponse DotNetMatt.

[rv26t]

@BasicZX81
En fait il est important de préciser au niveau de ton code les classes nommées DTO ne sont pas des DTO. Les DTO ne contiennent que des propriétés et constructeurs.
Or dans ton DTOBase tu as une quinzaines de méthodes, ce qui fait que ce ne peut pas être des DTO.
Après si cela répond à ton besoin, c'est simplement un choix technique différent.
C'est à mon avis une précision importante vis à vis des lecteurs qui ne connaissent pas les DTO, afin de ne pas créer de confusion.