Domain Service class

**sebRD** · 12/04/2011, 10h42

Bonjour à tous,

Je travaille actuellement sur un projet silverlight utilisant une base de données sql server 2008 r2.

Voici le contenu de la table sur laquelle je veux effectuer une requête:
Droit:

id : uniqueidentifier (PK)
Intervenant: : uniqueidentifier (FK Intervenant)
Projet : uniqueidentifier (FK Projet)
SousProjet : uniqueidentifier (FK SousProjet)
Espace : uniqueidentifier (FK Espace)
Bibliotheque : uniqueidentifier (FK Bibliotheque)

Les 4 derniers champs peuvent être combinés de différentes manières (avec des valeurs null). Dans ma logique applicative, je n'ai en aucun cas ces 4 champs différents de null en même temps.
Je cherche une méthode pour me renvoyer une liste d'"Intervenants" apparaissant dans la table "droit" avec les paramètres que je passe.
La méthode ci dessous me retourne à chaque fois aucun élément et je ne comprends pas pourquoi.

Code :

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

1
2
3
4
5
6
7
 
public IQueryable<Intervenant> GetIntervenantsDroit(Guid? projet, Guid? sousProjet, Guid? espace, Guid? bibliotheque)
        {
            return this.ObjectContext.Droits.Where(p => p.Projet == projet &&
p.SousProjet == sousProjet && p.Espace == espace && p.Bibliotheque ==
bibliotheque).Select(g => g.Intervenant1);
        }

Il me semblerait que Entity framework n'arrive pas à comparer des valeurs "null".

Merci pour vos réponses

**iberserk** · 15/04/2011, 12h17

Il me semblerait que Entity framework n'arrive pas à comparer des valeurs "null".

Normalement si...

p.SousProjet est bien un GUID?

Pouvez vous poster la requête SQL générée?
Au passage je vous déconseille fortement l'utilisation des GUID(uniqueidentifier) qui sont extrêmement contre-performant surtout en tant que PK/FK.

Je suis d'ailleurs choqué que MS s'en soit servi pour les tables de gestion des aspnet_users, membership etc...

**Bluedeep** · 15/04/2011, 12h46

Envoyé par iberserk

Au passage je vous déconseille fortement l'utilisation des GUID(uniqueidentifier) qui sont extrêmement contre-performant surtout en tant que PK/FK.

C'est quand même la manière la plus propre pour résoudre les problèmes de fusion de base en architecture utilisant la réplication de fusion.

Cela présente aussi un autre avantage ou plutôt élimine un gros inconvénient des IDs autoincrémentés : l'incomplétude d'un objet avant sa persistance, du fait que le GUID peut être affecté par le code créant l'instance, et découpler la question de l'existence d'un objet du problème de sa persistance.

En bref, je suis en désaccord.

Je suis d'ailleurs choqué que MS s'en soit servi pour les tables de gestion des aspnet_users, membership etc...

Moi pas.

**iberserk** · 15/04/2011, 17h53

qui sont extrêmement contre-performant

Je parle de problème de performance qui il est vrai est en général le dernier des soucis des développeurs....
Rassurez moi vous êtes au moins daccord sur ce point...

C'est quand même la manière la plus propre pour résoudre les problèmes de fusion de base en architecture utilisant la réplication de fusion.

Pouvez vous citer un exemple de problème rencontré avec les auto-incrément résolu par les GUID qui restent (lui aussi)un identifiant purement technique?

**Bluedeep** · 18/04/2011, 13h13

Envoyé par iberserk

Je parle de problème de performance qui il est vrai est en général le dernier des soucis des développeurs....
Rassurez moi vous êtes au moins daccord sur ce point...

Je suis d'accord sur le fait que cela soit moins performant.

Par contre avez vous fait des mesures chiffrées pour donner une idée de l'étendue des dégats ?

Pouvez vous citer un exemple de problème rencontré avec les auto-incrément résolu par les GUID qui restent (lui aussi)un identifiant purement technique?

Comme mentionné supra : fusion de bases. (et de toute manière un PK n'est en aucun cas censée être un identifiant métier).

**iberserk** · 18/04/2011, 15h10

Par contre avez vous fait des mesures chiffrées pour donner une idée de l'étendue des dégats ?

Voici une requête qui ne nécessite aucune mesure supplémentaire

Code :

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

1
2
SELECT DATALENGTH(CAST (4 as integer)) as integerLength,
       DATALENGTH(NEWID()) as UniqueIdentifierLength

Résultat: integerLength: 4: UniqueIdentifierLength 16

Ratio de 4 pour 1...
Mettriez vous vos PK en CHAR(16) tout en considérant que cela reste une donnée technique?

Comme mentionné supra : fusion de bases.

En clair vous sacrifiez les performances générales de votre base de données (uniqueidentifier propagés dans toute votre base...) uniquement pour simplifier la vie des personnes chargées du développement des lots/batch de fusion...

et de toute manière un PK n'est en aucun cas censée être un identifiant métier

Vous voyez qu'on peut être daccord

Je conçois que cela puisse être pratique... il s'agissait juste d'une préconisation pour notre ami, qui, j'en douterais ne doit pas être sur une réplication de fusion ici.