Discussion :

[tomlev]

Salut,

Peut-on, en utilisant le designer LINQ to SQL, modéliser des "self-associations" (je vois pas trop comment le dire en français...) ? Autrement dit, une ligne d'une table pointe vers N autres lignes de la même table ?

Au niveau data-model, c'est assez simple, il suffit de créer une table d'association, malheureusement LINQ ne modélise pas l'association comme je voudrais. Ce sera plus clair avec un exemple concret:

J'ai créé une petite base de données sous SQL Server, avec le schéma suivant:


Une ligne de user pointe vers N autres lignes de user via la table contact_list.

J'ai ensuite créé la DAL avec le designer LINQ, cela donne le schéma suivant:


Le designer me génère une propriété pour l'association User->ContactList, malheureusement (et c'est logique en fait) cette propriété n'est pas de type EntitySet<User>, mais de type EntitySet<ContactList>... ce qui fait que c'est beaucoup moins pratique à manipuler !

Code C# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
		[Association(Name="user_contact_list1", Storage="_Contacts", ThisKey="Id", OtherKey="UserId")]
		public EntitySet<ContactList> Contacts
		{
			get
			{
				return this._Contacts;
			}
			set
			{
				this._Contacts.Assign(value);
			}
		}

La classe ContactList ne correspond à rien de concret, elle a juste un rôle technique pour réaliser l'association, donc j'aimerais mieux ne pas avoir à m'en servir dans le code.

Y a-t-il a une manière de modéliser ça correctement, si possible en utilisant le designer ?

J'ai bien une idée pour le faire à la main, mais ça me semble pas idéal... comme je ne peux pas modifier le code auto-généré (la regénération écrasera mes modifs), je pensais créer une autre partie de la classe (elle est déclarée partial) dans un autre fichier, pour ajouter une propriété permettant d'accéder directement aux users de la contact list:

Code C# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
    public partial class User
    {
        public EntitySet<User> TheContacts
        {
            get
            {
                EntitySet<User> contacts = (from ContactList cl
                                            in this.Contacts
                                            select cl.Contact) as EntitySet<User>;
                return contacts;
            }
        }
 
    }

En attendant mieux, je vais faire comme ça, mais si vous avez mieux je suis preneur !

Je sais pas si j'ai été très clair, donc n'hésitez pas à poser des questions.

Merci !

[SaumonAgile]

Autrement dit, une ligne d'une table pointe vers N autres lignes de la même table ?

Il y a une incohérence entre tes schémas et cette phrase. Ton schéma ne fait pas apparaitre de table qui possède une clé vers cette même table. Par exemple, User n'a pas de clé vers User et ContactList n'a pas de clé vers ContactList.

Pourrais tu vérifier que tous les énoncés sont corrects ?

EDIT : A moins que ton User soit aussi ce que tu appelles un Contact ? C'est ça ?

REDIT : http://blogs.msdn.com/mitsu/archive/...nq-to-sql.aspx

REREDIT : http://www.chrisbrandsma.com/2007/08...ables-and.html

[tomlev]

Il y a une incohérence entre tes schémas et cette phrase. Ton schéma ne fait pas apparaitre de table qui possède une clé vers cette même table. Par exemple, User n'a pas de clé vers User et ContactList n'a pas de clé vers ContactList.

Pourrais tu vérifier que tous les énoncés sont corrects ?

Non non, il n'y a pas d'incohérence... en fait les flèches sont créées par le designer, et ne reflètent pas le sens "fonctionnel" de l'association:
Dans contact_list, les colonnes user_id et contact_id sont toutes les 2 des clés étrangères qui pointent vers user.id.
Je ne peux pas mettre dans user un champ qui pointe directement vers un autre user.id, parce que dans ce cas chaque utilisateur ne pourrait avoir qu'un contact... c'est pour ça qu'il y a une table d'association séparée.

En fait, sur le schéma fonctionnel, contact_list ne devrait pas apparaître, il devrait simplement y avoir une relation N-N qui boucle sur user.

Malheureusement LINQ ne semble pas faire la différence entre la structure technique et la structure fonctionnelle...

[SaumonAgile]

Et tu avais vu ma pelle de EDIT ?

[tomlev]

Et tu avais vu ma pelle de EDIT ?

Ah non, j'avais pas vu
Je jette un coup d'oeil et je reviens !

[tomlev]

EDIT : A moins que ton User soit aussi ce que tu appelles un Contact ? C'est ça ?

REDIT : http://blogs.msdn.com/mitsu/archive/...nq-to-sql.aspx

REREDIT : http://www.chrisbrandsma.com/2007/08...ables-and.html

Oui, un contact est un user.

Super les liens, c'est exactement ce que je cherchais . Mon cas est juste un cas particulier d'une relation "many to many" en fait...

Par contre, ça confirme que je craignais...

Linq to Sql does not support definition of “many to many” relationships. This means that there is no specific relation attribute that allows defining such a complex relation. So you have to create as many entities as you physical model does and define your intermediate table on the code side.

Je vais donc le faire à la main, tant pis

Merci en tous cas !