Modélisation d'objets connexes

Question

Je suis en train de concevoir une application qui traite deux ensembles de données - Utilisateurs et zones. Les données sont lues à partir de fichiers produits par un tiers. J'ai une classe User et une classe Area, et les données sont lues dans un tableau Users et un tableau Areas (ou toute autre structure de mémoire appropriée, selon la technologie utilisée).

Les deux classes ont un membre d'ID unique qui est lu à partir du fichier, et la classe User contient un tableau d'ID de zone, donnant une relation où un utilisateur est associé à plusieurs zones.

Les exigences sont assez simples:

• Liste des utilisateurs
• Liste des zones
• Liste des utilisateurs pour la zone spécifiée
• Liste des zones pour certains utilisateurs

Mon La première pensée était de laisser les données dans les deux tableaux, puis pour chacune des exigences, ont une méthode séparée qui d interroger un ou les deux réseaux, selon les besoins. Ce serait facile à mettre en œuvre, mais je ne suis pas convaincu que ce soit nécessairement la meilleure solution. Puis j'ai pensé à avoir une méthode 'Get Areas' sur la classe User et un membre 'Get Users' sur la classe Area qui serait plus utile si par exemple je suis à un stade où j'ai un objet Area , Je pourrais trouver ses utilisateurs par une propriété, mais alors comment une méthode 'Get Users' sur la classe Area serait-elle au courant/aurait-elle accès au tableau Users.

J'ai déjà eu ce problème plusieurs fois, mais je n'ai jamais vraiment trouvé de solution définitive. Peut-être que je suis en train de le rendre plus compliqué qu'il ne l'est en réalité. Quelqu'un peut-il fournir des conseils, des URL ou des livres qui pourraient m'aider avec ce type de conception?

MISE À JOUR: Merci à tous d'avoir pris le temps de nous donner quelques conseils. Vos commentaires sont très appréciés. Je suis d'accord que la racine de ce problème est une relation plusieurs-à-plusieurs. Je comprends comment cela serait modélisé dans une base de données relationnelle, c'est assez simple. Les données que je reçois sont sous la forme de fichiers binaires provenant d'un tiers, donc je n'ai aucun contrôle sur la structure de celles-ci, mais je peux les stocker de la manière qui me convient le mieux lorsque je les lis. C'est un peu piquets carrés dans les trous ronds, mais je pensais le lire puis le stocker dans une base de données, le programme devrait alors interroger la base de données pour obtenir les résultats. Ce n'est pas une quantité massive de données, alors j'ai pensé qu'il serait possible de sortir ce dont j'ai besoin en le stockant dans des structures de mémoire. Pourquoi ne pas utiliser DataTables avec des relations, si .NET est impliqué?

Answer 1

Vous voudrez peut-être aussi vous pencher sur Generics, si .NET est impliqué.

Answer 2

cela est vraiment un grand nombre à plusieurs,

User <<--->> Area 

diviser en 3 objets, l'utilisateur, la région et UserArea:

User: Id, name, etc. 
Area: Id, name, etc. 
UserArea: UserId, AreaId 

Answer 3

Est une zone appartenant à plusieurs utilisateurs ? Si oui, c'est techniquement une relation plusieurs-à-plusieurs. Si vous deviez transformer les données dans une base de données relationnelle, vous créeriez une table avec toutes les relations.Je suppose que si vous voulez travailler avec des tableaux, vous pouvez créer un troisième tableau. Ou si vous voulez réellement faire cela d'une manière OO, les deux classes doivent avoir des tableaux de pointeurs vers les zones/utilisateurs associés.

Answer 4

Une option consiste à utiliser un dictionnaire pour chacune des 2 dernières exigences. C'est-à-dire un Dictionary<Area, List<User>> et un Dictionary<User, List<Area>>. Vous pouvez les construire en lisant les données. Vous pourriez même envelopper une classe autour de ces 2 dictionnaires, et avoir juste une méthode sur cette classe pour chacune des exigences. Cela vous permettra de vous assurer que les dictionnaires restent synchronisés.

Answer 5

Très basique, mais l'idée est:

struct/class Membership 
{ 
    int MemberID; 
    int userID; 
    int areaID; 
} 

Cette classe implémente le concept d'appartenance « utilisateur appartient à la zone ». Collez l'un d'entre eux pour chaque appartenance à une collection et interrogez cette collection pour les sous-ensembles qui répondent à vos besoins.

EDIT: Une autre option

Vous pouvez stocker dans chaque membre une liste des zones, et dans chaque région, une liste des membres.

dans la zone:

public bool addMember(Member m) 
{ 
    if (/*eligibility Requirements*/) 
    { 
     memberList.add(m); 
     m.addArea(this); 
     return true; 
    } 
    return false; 
} 

et une mise en œuvre similaire membre (sans rappel)

L'avantage est qu'il est assez facile de retourner un itérateur de se promener dans une région et trouver des membres (et vice versa)

L'inconvénient est qu'il est très étroitement couplé, ce qui pourrait causer des problèmes futurs.

Je pense que la première implémentation est plus compatible avec LINQ.

Answer 6

Je suis désolé, mais ce n'est pas un problème orienté objet. C'est un problème relationnel. D'où toutes les références à la cardinalité (many-to-many). C'est une modélisation de base de données relationnelle 101. Je ne veux pas critiquer Gavin, juste pour souligner une nouvelle perspective.

Alors à quoi bon est ma diatribe. La réponse devrait être d'intégrer avec un magasin de données relationnelles, pas de le marteler dans un paradigme orienté objet. C'est le problème classique du trou carré.

Answer 7

D'accord avec dacracot

Regardez aussi DevExpress XPO