Моделирование связанных объектов

Question

Я разрабатываю приложение, которое имеет дело с двумя наборами данных - пользователями и областями. Данные считываются из файлов, созданных третьей стороной. У меня есть класс User и класс Area, и данные считываются в массив Users и массив Areas (или другую соответствующую структуру памяти, в зависимости от технологии, с которой мы работаем).

В обоих классах есть уникальный идентификатор, который считывается из файла, а класс User содержит массив идентификаторов областей, что дает отношения, когда один пользователь связан со многими областями.

Требования достаточно прост:

• Список пользователей
• Список областей
• Список пользователей для указанной области
• Список областей для определенных пользователей

Моих первая мысль заключалась в том, чтобы оставить данные в двух массивах, тогда для каждого из требований есть отдельный метод, который d запрашивать один или оба массива по мере необходимости. Это было бы легко реализовать, но я не уверен, что это обязательно лучший способ.

Затем я подумал о том, что метод «Получить районы» для класса «Пользователь» и «Получить пользователей» в классе Area был бы более полезен, если, например, я на этапе, когда у меня есть объект Area , Я мог бы найти его пользователями по свойству, но тогда как метод «Получить пользователей» в классе Area должен был знать/иметь доступ к массиву Users.

У меня была эта проблема несколько раз раньше, но на самом деле не придумал окончательного решения. Возможно, я просто делаю это более сложным, чем на самом деле. Может ли кто-нибудь предоставить какие-либо советы, URL-адреса или книги, которые помогут мне с таким дизайном?

ОБНОВЛЕНИЕ: Спасибо, что нашли время, чтобы оставить несколько советов. Ваши комментарии очень ценятся.

Я согласен с тем, что корень этой проблемы является отношением «многие ко многим». Я понимаю, как это будет смоделировано в реляционной базе данных, это довольно просто.

Данные, которые я получаю, представлены в виде двоичных файлов от третьего лица, поэтому я не могу контролировать их структуру, но я могу сохранить его в зависимости от того, какой способ лучше, когда я его прочитал. квадратные колышки в круглых отверстиях, но я думал, что прочитал его, а затем сохранил его в базе данных, тогда программа должна была бы запросить базу данных, чтобы получить результаты. Это не массивный объем данных, поэтому я подумал, что можно будет получить то, что мне нужно, сохранив его в структурах памяти.

Answer 1

Почему бы не использовать DataTables с отношениями, если .NET участвует? Возможно, вы захотите также взглянуть на Generics, если задействовать .NET.

Answer 2

это действительно многие-ко-многим,

User <<--->> Area 

разбить его на 3-х объектов, пользователей, площадь и UserArea:

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

Answer 3

ли область принадлежит нескольким пользователям ? Если да, это технически соотношение «многие ко многим». Если бы вы преобразовали данные в реляционную базу данных, вы создали бы таблицу со всеми отношениями.Я думаю, если вы хотите работать с массивами, вы можете создать третий массив. Или, если вы действительно хотите сделать это с помощью OO, оба класса должны иметь массивы указателей для связанных областей/пользователей.

Answer 4

Один из вариантов - использовать словарь для каждого из последних 2 требований. То есть, Dictionary<Area, List<User>> и Dictionary<User, List<Area>>. Вы можете создать их, когда будете читать данные. Вы можете даже обернуть класс вокруг этих 2 словарей и просто иметь метод для этого класса для каждого из требований. Это позволит вам синхронизировать словари.

Answer 5

Очень простой, но идея:

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

Этот класс реализует «пользователь принадлежит к области» концепции членства. Прикрепите один из них для каждого членства в коллекции и запросите эту коллекцию для подмножеств, соответствующих вашим требованиям.

EDIT: Еще один вариант

Вы можете хранить в каждом государстве-члене список областей, и в каждой зоне, список членов.

в зоне:

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

и аналогичной реализации в член (без обратного вызова)

Преимущество этого в том, что это довольно легко вернуть итератор, чтобы пройти через область и найти пользователей (и наоборот)

Недостатком является то, что он очень плотно соединен, что может стать причиной будущих проблем.

Я думаю, что первая реализация более удобна для LINQ.

Answer 6

Извините, но это не объектно-ориентированная проблема. Это реляционная проблема. Следовательно, все ссылки на мощность (многие-ко-многим). Это моделирование реляционной базы данных 101. Я не хочу критиковать Гэвина, просто чтобы указать на новую перспективу.

Итак, какая польза от моей напыщенности. Ответ должен заключаться в интеграции с реляционным хранилищем данных, а не в его объектно-ориентированной парадигме. Это классическая квадратная привязка, проблема с круглым отверстием.

Answer 7

Согласен с dacracot

Также обратите внимание на DevExpress XPO