Discussion :

[mactwist69]

Bonjour bonjour,

après recherches, je n'arrive pas à faire fonctionner quelque chose et je suis pourtant certain de ne pas être le premier :


J'ai un projet transverse (PROJET1) de type DTO (classes ne contenant que des propriétés)
Parmi ces classes : des propriétés Public, et des propriétés Friend.

J'ai un PROJET2 qui gère l'utilisation de ces DTO.
(Donc projet2 à une référence sur projet1)

-> J'ai des propriétés Friend car je voudrais que certaines de ces propriétés ne soient visibles que depuis le PROPJET2, mais sinon personne d'autres.

En cherchant, je n'ai trouvé que cette solution : Utiliser le friend assembly dans le projet 1 : <Assembly: InternalsVisibleTo("Projet2")>

Mais rien n'y fait, il ne veut pas utiliser ma variable, "car elle est Friend"...

Qu'est ce que je rate ??

EDIT : Bien évidemment, comme il s'agit de deux projets, impossible de partager le même namespace...

[mactwist69]

Je reformule pour être moins compliqué (je l’espère) :

Est il possible de rendre certaines propriétés (non publiques) d'une classe Accessible depuis un autre projet spécifique ?

[Kropernic]

Hello Mactwist,

Je n'ai malheureusement pas de réponse à te donner sur le plan technique mais je me pose une question sur le plan conceptuel.

Pourquoi diable souhaites-tu faire cela ?

[mactwist69]

Hello,

Et bien voilà :

De base, en POO, une classe va avoir des propriétés public, d'autre private avec des méthodes publiques qui vont manipuler ces deux types de propriétés.

Bon, quand on développe en couche... on utilise des DTO, et on a aussi des classes qui manipule ces DTO (pour charger, enregistrer).

D'habitude, j'imagine, que les DTO et les classes sont dans le même projet...

Ce qui fait que les propriétés Friend des DTO sont manipulables par les classes, mais invisible pour le développeur. (tout comme les propriétés private des classes classiques)

Mais dans mon cas, pas le choix, ces fameuse classes qui manipulent les DTO se trouvent dans un autre projet... architecture oblige...
C'est un service qui va s'occuper de faire ces opérations (Save, Load etc.)

EDIT : En voyant une réponse, tu m'as donné un faux espoir Kropernic !!

Une solution HYPER moche, serait d'écrire ces propriétés friend en publiques, puis de les rendre invisible à l'intellisense.. Mais bon, c'est horrible quoi.

[Kropernic]

Je reformule ma question :

Pourquoi as-tu des propriétés Friend dans un DTO ?

Un DTO ne contient que les infos de base. Rien à cacher donc. Non ?

[mactwist69]

Parce que mes DTO ont des propriétés "métier" : La vrai info, le Vrai DTO comme on l'entends.

Et qu'il y a des infos "internes de fonctionnement" du type : "J'existe", "mon ID de Base de données"
Et ceux là, je veux les cacher...

Donc j'ai trois choix :

- Soient j'arrivent a étendre le Friend à un autre projet.

- soient je supprime ces infos... Mais à chaque méthode de ma classe qui manipule les DTO, elles devront recalculer ces infos à chaque fois pour savoir quoi faire avec (vérifier l'existence pour ajout, mise a jour etc...)

- Soient je rends tout publique, au risque que les développeurs manipule ces données d'une mauvaise manière.

[Kropernic]

Donc si je comprends, tu voudrais par exemple que la couche BLL ne puisse pas accéder à l'id lorsqu'elle manipule le DTO mais que, lorsqu'elle le transmet à la couche DAL (pour le persister en DB par exemple), cette dernière pourra accéder à l'id pour faire son boulot.

C'est bien ça ?

J'suis loin d'être un pro en architecture mais cela me semble quand même bizarre cette affaire-là.

J'espère que quelqu'un pourra te répondre !

[mactwist69]

C'est presque ça :

Je souhaite que dans le projet Interface Utilisateur, on importe le projet DTO et qu'on ne manipule que les données métier.

Mais que la BLL, elle, puisse utiliser des propriétés "private" de ces même DTO.

[Kropernic]

- soient je supprime ces infos... Mais à chaque méthode de ma classe qui manipule les DTO, elles devront recalculer ces infos à chaque fois pour savoir quoi faire avec (vérifier l'existence pour ajout, mise a jour etc...)

Si ces infos sont calculables, c'est qu'il ne s'agit pas d'infos de base :-/
Pour le CRUD, il y a MERGE en SQL qui évite d'avoir à s'emmerder dans la BLL pour savoir si on doit apperler DAL.Insert ou DAL.Update (dans de s'emmerder dans la DAL si on a opté pour DAL.Save).

- Soient je rends tout publique, au risque que les développeurs manipule ces données d'une mauvaise manière.

Si tu as peur qu'ils modifient l'id par exemple, rend le ReadOnly et ça répond au besoin non ? Ou bien le dev ne peux vraiment pas connaître l'id de l'objet en DB ?

[mactwist69]

BAh non, ma BLL doit pouvoir remplir l'info ID ,donc pas de readè-only
Et je veux le faire qu'une seule fois au chargement....

Et je veux pas que n'importe qui puisse changer l'info...

[Kropernic]

BAh non, ma BLL doit pouvoir remplir l'info ID ,donc pas de readè-only
Et je veux le faire qu'une seule fois au chargement....

Et je veux pas que n'importe qui puisse changer l'info...

Le problème ne serait-il pas là ? Ce n'est pas la BLL qui doit remplir l'id. Ou alors, uniquement via le constructeur. Mais vu que normalement, l'objet est créé dans la DAL s'il vient de la DB ou "sans id" s'il est nouveau. Non ?

Sinon, j'ai quand même p-e une solution de contournement pour toi. Tu peux les masquer dans l'intellisense avec l'attribut EditorBrowsable(EditorBrowsableState.Never).
C'est pas top mais c'est toujours un début :-/

[DotNetMatt]

Sinon, j'ai quand même p-e une solution de contournement pour toi. Tu peux les masquer dans l'intellisense avec l'attribut EditorBrowsable(EditorBrowsableState.Never).
C'est pas top mais c'est toujours un début :-/

Ca ne marchera que si la DLL est importée. Si on ajoute une référence au projet directement, ca ne marche pas

Sinon mactwist69 je ne vois aucun intérêt à faire ca à part se prendre le chou inutilement... Imagine si chaque développeur créait sa propre tambouille dans un coin et puis décidait de la rendre invisible aux autres. WTF

[mactwist69]

En fait le problème vient du fait que j'avais une seule classe...
Et que j'ai voulu en faire un DTO + une classe de méthodes... et que ça marche pas comme ça...

Donc tant pis, je vais réecrire en faisant des vrais DTO...

+1 DotNetMatt, je pensais gagner du temps... et finalement ça allait juste être moche.
Il m'a fallu l'aprem pour ne plus être dans le dénie !!!

[Kropernic]

Au final, j'avais raison depuis le début en fait ?

[mactwist69]

Tout à fait...

C'est toi qui m'a convaincu d'ailleurs... juste avant que DotNetMAtt confirme le n'importe quoi.