Discussion :

[tomlev]

Salut,

Je me pose des questions sur la meilleure façon de faire ce que je veux, d'un point de vue conception... Je fais une appli client-serveur (un système de messagerie instantanée, type MSN) qui utilise WCF pour la communication et LINQ pour modéliser la base de données des utilisateurs.

Côté serveur, pas de problème, le DataContext est généré par VS et je peux manipuler mes objets comme je veux.

Maintenant, j'aimerais pouvoir transmettre à un utilisateur connecté des infos sur d'autres utilisateurs. Le plus simple serait donc de simplement envoyer les objets du DataContext, seulement ils contiennent des infos que je ne veux pas transmettre aux utilisateurs. Par exemple, la classe User contient une propriété ContactList, mais je ne veux pas qu'un user A puisse accéder à la contact list d'un utilisateur B.

Donc, je vois 2 options :

1.Contrôler la sérialisation pour ne pas sérialiser les infos qui ne doivent pas être transmises
Avantages : c'est propre, et transparent à l'utilisation
Inconvénients : je ne suis pas sûr que ce soit possible... j'ai bien vu des méthodes OnSerializing, On Deserializing, etc, mais elles sont générées automatiquement par le Designer, et si je les modifie mes modifs sont écrasées par le designer

2. Utiliser une autre classe pour transmettre les données sur un utilisateur
Avantages : c'est simple
Inconvénients : Je dois créer un nouvel objet à chaque fois au lieu d'utiliser celui qui existe déjà. Et c'est pas beau je n'aime pas trop avoir 2 classes qui représentent la même chose...

Quelle est à votre avis la meilleure solution (par forcément une de celles que j'ai décrites...) ?
Pour la solution 1, est-ce qu'il est possible de contourner le problème du designer LINQ qui écrase mes modifs ? (à part en créant le DataContext manuellement bien sûr...)

Merci pour vos lumières

[The_badger_man]

Je me pose des questions sur la meilleure façon de faire ce que je veux, d'un point de vue conception... Je fais une appli client-serveur (un système de messagerie instantanée, type MSN) qui utilise WCF pour la communication et LINQ pour modéliser la base de données des utilisateurs.

ça me rappelle quelque chose ce truc

Au départ mon tuto de chat en WCF devait être un tuto sur messagerie instantanée WCF. Mais j'ai été confronté aux même pb que toi et je suis passé sur un chat parceque c'était plus simple à expliquer .

Quelle est à votre avis la meilleure solution (par forcément une de celles que j'ai décrites...) ?

la 2 (ce n'est que mon avis)

2. Utiliser une autre classe pour transmettre les données sur un utilisateur
Avantages : c'est simple
Inconvénients : Je dois créer un nouvel objet à chaque fois au lieu d'utiliser celui qui existe déjà. Et c'est pas beau je n'aime pas trop avoir 2 classes qui représentent la même chose...

Oui mais justement (pour moi) ces 2 classes ne représentent pas la même chose. Celle de Linq sert à manipuler les données de ta base, l'autre est la "classe métier coté service" (j'ai un doute sur cette expression ).

Je ne suis pas un expert mais je pense que c'est une erreur d'utiliser les classes générées par le designer Linq to SQL dans toutes les couches de l'appli. Elles ne doivent servir qu'à communiquer avec la base. Ce ne sont pas tes classes "métier".

[tomlev]

ça me rappelle quelque chose ce truc

Contrairement à ce que tu pourrais croire, ce n'est pas ton tuto qui m'a donné cette idée
C'est simplement le premier truc qui m'est venu à l'esprit quand j'ai voulu essayer WCF... Par contre ce que j'ai lu dans ton tuto m'a permis d'apporter pas mal d'améliorations à ce que j'avais fait

Bref, je suis parti sur la solution 2... que ce soit ou non la meilleure, c'est la seule que je sache implémenter de toutes façons !

Merci de ta réponse

[Thomas Lebrun]

Moi, je conseillerais plutôt la première solution

Les méthodes OnSerializing, OnDeserializing sont des méthodes partielles (nouveauté C# 3). Cela veut dire qu'elles sont utilisées mais pas déclarées: lors de la compilation, le compilateur voit qu'elles ne sont pas déclarées et donc, il supprime les appels à ces méthodes.

Le mieux pour toi est de créer, dans un autre fichier, la suite de la classe partielle que représente ton DataContext. Dans ce fichier, tu pourras implémenter les méthodes partielles (tu tapes "partial" et en appuyant sur Espace, l'intellisense de VS te propose la liste des méthodes à implémenter).

Dans le cas où tu fais des modifs sur ta base/ton DataContext, les méthodes ne sont pas écrasées car elles sont dans un autre fichier. Pour info, c'est la technique à utiliser


A+

[SaumonAgile]

Moi, je conseillerais plutôt la première solution

+1

J'utilise LINQ et WCF dans un projet chez un client, et les objets du datacontext sont utilisés comme objets pauvres, ça simplifie les choses, et les méthodes et classes partielles permettent d'affiner le fonctionnement.

[tomlev]

Moi, je conseillerais plutôt la première solution

Les méthodes OnSerializing, OnDeserializing sont des méthodes partielles (nouveauté C# 3). Cela veut dire qu'elles sont utilisées mais pas déclarées: lors de la compilation, le compilateur voit qu'elles ne sont pas déclarées et donc, il supprime les appels à ces méthodes.

Le mieux pour toi est de créer, dans un autre fichier, la suite de la classe partielle que représente ton DataContext. Dans ce fichier, tu pourras implémenter les méthodes partielles (tu tapes "partial" et en appuyant sur Espace, l'intellisense de VS te propose la liste des méthodes à implémenter).

Dans le cas où tu fais des modifs sur ta base/ton DataContext, les méthodes ne sont pas écrasées car elles sont dans un autre fichier. Pour info, c'est la technique à utiliser


A+

Ca me plait bien ce que tu me dis là... Je pensais avoir fait le tour des nouveautés du langage, mais j'avais raté ça !

Par contre ce qui m'embête, c'est que chez moi, les méthodes en question ne sont pas déclarées comme partielles et elles sont déjà implémentées par le designer

Code C# :

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

1
2
3
4
5
6
7
 
[OnSerializing()]
[System.ComponentModel.EditorBrowsableAttribute(EditorBrowsableState.Never)]
public void OnSerializing(StreamingContext context)
{
    this.serializing = true;
}

Est-ce qu'il y a quelque chose de spécial à faire pour obtenir le comportement que tu décris ?

[SaumonAgile]

Tu utilises quelle version de VS 2008 ?
Tu as bien défini le SerializationMode à Unidirectional dans le fichier dbml ?

[tomlev]

Tu utilises quelle version de VS 2008 ?

VS2008 Pro (version finale)

Tu as bien défini le SerializationMode à Unidirectional dans le fichier dbml ?

Oui

[Thomas Lebrun]

Ah oui, je viens de regarder et ces méthodes sont bien implémentées chez moi aussi

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
 
[OnDeserializing()]
		[System.ComponentModel.EditorBrowsableAttribute(EditorBrowsableState.Never)]
		public void OnDeserializing(StreamingContext context)
		{
			this.Initialize();
		}
 
		[OnSerializing()]
		[System.ComponentModel.EditorBrowsableAttribute(EditorBrowsableState.Never)]
		public void OnSerializing(StreamingContext context)
		{
			this.serializing = true;
		}
 
		[OnSerialized()]
		[System.ComponentModel.EditorBrowsableAttribute(EditorBrowsableState.Never)]
		public void OnSerialized(StreamingContext context)
		{
			this.serializing = false;
		}

Je pense que dans ce cas, tu peux essayer de faire tes propres méthodes qui seront appellées lors de la serialisation/deserialisation (via les attributs). Il faut juste que tu penses que ces méthodes doivent renvoyer void et prendre en paramètres un StreamingContext

[tomlev]

OK, je vais voir ce que dit la doc sur les attributs OnSerialized, OnSerializing, etc... ça devrait me permettre de faire ce que je veux.
Merci pour votre aide !

[tomlev]

Bon, ça semble effectivement faisable avec cette méthode... mais il reste un gros inconvénient auquel je n'avais pas pensé au début : pour utiliser les classes d'entités LINQ, le client doit référencer l'assembly qui les définit... or je ne veux pas déployer cet assembly (qui contient des infos sur la structure de la base) sur les postes clients.

Bref, comme disait badger, ce n'est sans doute pas une bonne pratique d'utiliser les classes de la DAL comme classes métier.

Donc je crois que je vais m'en tenir à la solution 1, même si elle ne me satisfait pas complètement...

[Thomas Lebrun]

En fait, ce qu'il fautdrait arriver à faire, c'est mettre dans une asssembly externe les classes générées par le DBML.

Cela permettrait d'échanger ces classes entre les différentes couches de l'application

[SaumonAgile]

En fait, ce qu'il fautdrait arriver à faire, c'est mettre dans une asssembly externe les classes générées par le DBML.

Cela permettrait d'échanger ces classes entre les différentes couches de l'application

C'est ce que je fais.
4 projets pour le serveur :
- Entities (contient le DBML)
- DAL (contient le LINQ et référence Entities)
- BLL (Utilise la DAL et référence Entities)
- Services (WCF, référence Entities et sérialise les objets)

Pour les clients (c'est une appli multi-clients) :
5 projets :
- Expert pour l'administration (.NET 3.5)
- Mobile pour les agents de terrain (.NET 3.5)
- CeMobile pour les agents de terrain (Compact 3.5)
- Services (contient les proxies WCF, évite les duplications d'objets liés à des références multiples dans plusieurs projets)
- Library (contient les écrans commun aux projets Expert et Mobile).

[anthyme]

Bonjour !

Ayant le même problème (voir quelques sujets plus loin) on m avait conseillé l'inverse

perso je prefere cette façon de faire mais comment marquer les propriété avec des [DataContract] et [DataMember] ?

[tomlev]

C'est ce que je fais.
4 projets pour le serveur :
- Entities (contient le DBML)
- DAL (contient le LINQ et référence Entities)
- BLL (Utilise la DAL et référence Entities)
- Services (WCF, référence Entities et sérialise les objets)

Pour les clients (c'est une appli multi-clients) :
5 projets :
- Expert pour l'administration (.NET 3.5)
- Mobile pour les agents de terrain (.NET 3.5)
- CeMobile pour les agents de terrain (Compact 3.5)
- Services (contient les proxies WCF, évite les duplications d'objets liés à des références multiples dans plusieurs projets)
- Library (contient les écrans commun aux projets Expert et Mobile).

Euh, là je suis un peu perdu... il me semble que la couche DAL est géré par le DataContext, non ? Et donc DAL = Entities...

Bonjour !

Ayant le même problème (voir quelques sujets plus loin) on m avait conseillé l'inverse

perso je prefere cette façon de faire mais comment marquer les propriété avec des [DataContract] et [DataMember] ?

Justement, le designer LINQ le fait quand tu mets SerializationMode à Unidirectional. Le problème c'est qu'il les met sur toutes les propriétés, tu ne peux pas contrôler au cas par cas...

[anthyme]

ah ok un peu moins propre mais plus pratique

Bin faut intercepter le passage par la couche service et mettre a null les champs qu'on ne veut pas faire transiter (comme un password par exemple).

Non ?

[SaumonAgile]

Euh, là je suis un peu perdu... il me semble que la couche DAL est géré par le DataContext, non ? Et donc DAL = Entities...

Non car pour nous une entité est simplement un conteneur de données. Elle transite entre les couches. Sinon ça obligerait à référencer la DAL dans la couche Services. Notre approche utilise le dbml pour générer les objets pauvres que nous générions avant avec d'autres outils. Effectivement la seule "incohérence" est que le contexte est visible dans le service par le référencement des entités. Mais nous choisissons de ne pas l'utiliser (car les objets en eux-même n'ont pas de lien avec le contexte).

Dernière chose, la DAL est une couche séparée car aussi puissant que peut être LINQ certaines choses peuvent encore nécessiter d'être écrites à la main (requête très complexe, modification de structure ?, etc)

[Thomas Lebrun]

Effectivement, le fait de prendre le code du DBML et de le considérer comme étant les entités est une bonne idée. Ainsi, dans ta DAL, tu peux faire appel au DataContext, etc....

[tomlev]

ah ok un peu moins propre mais plus pratique

Bin faut intercepter le passage par la couche service et mettre a null les champs qu'on ne veut pas faire transiter (comme un password par exemple).

Non ?

C'est ce que je ferais aussi...

Non car pour nous une entité est simplement un conteneur de données. Elle transite entre les couches. Sinon ça obligerait à référencer la DAL dans la couche Services. Notre approche utilise le dbml pour générer les objets pauvres que nous générions avant avec d'autres outils. Effectivement la seule "incohérence" est que le contexte est visible dans le service par le référencement des entités. Mais nous choisissons de ne pas l'utiliser (car les objets en eux-même n'ont pas de lien avec le contexte).

Dernière chose, la DAL est une couche séparée car aussi puissant que peut être LINQ certaines choses peuvent encore nécessiter d'être écrites à la main (requête très complexe, modification de structure ?, etc)

OK, j'y vois un peu plus clair, merci

Finalement la seule chose gênante dans le fait d'utiliser les objets générés par le designer, c'est que les attributs des membres donnent des infos sur la structure de la base. Pas génial d'un point de vue sécurité, mais bon, je peux vivre avec...

[anthyme]

oué enfin pour mon problème perso cette solution me convient pas tout a fait car si la "cible" décompile le code client il a tout le schéma de la base de données donc bof