Этот дизайн класса слишком близок к структуре таблицы БД?

Question

У меня есть БД со следующими таблицами Элементы , Группы и GroupItems . Таблица Items содержит настройки каждого элемента, таблица groups содержит определение некоторых групп, а таблица GroupsItems содержит ссылку каждого элемента на каждую группу и дату, когда элемент был добавлен в группу, и дату, когда элемент был удалено (если есть).

В моей модели C # у меня есть 3 класса:

• class Item
• class Group
• class GroupItem

Класс Group имеет коллекцию GroupItems, и каждый класс GroupItem содержит один элемент, а также добавленную и удаленную дату, если таковая имеется.

Я не уверен, что это хороший дизайн или я перемещаю структуру БД в свою модель приложения. Было бы лучше, если бы я переместил две даты прямо в класс Item и сократил количество классов на один, а значит и сложность программного обеспечения?

Что ты думаешь?

Answer 1

Если вы можете , удалив класс GroupItem и "разделить" его на Item в вашей архитектуре, это хороший выбор.Единственное, что вам нужно учесть, это то, что вы должны переназначить отображение вашей БД на этом этапе.

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

Я лично отстаивал бы чистое отображение и оставляю все как есть.Как и через пару месяцев, вы никогда не будете помнить, какой файл был связан, и наличие уже относительно когерентного отображения между вашими code model и db model поможет упростить все вещи понимаю, ИМО .

Answer 2

Кажется, что GroupItem является квалифицированной ассоциацией между Group и Item.

Вопрос, который вы должны задать себе, заключается в том, действительно линужна квалифицированная ассоциация или нет.Учитывая очень общие имена ваших энтузиастов, я не знаю.Необходимо рассмотреть три случая:

• Если предмет удерживается только одной группой, вам не нужна квалифицированная ассоциация: информация (т.е. дата) в ассоциации может бытьпереехал в пункт.Это простая связь один-ко-многим .У Group есть список Item, и вам не нужна дополнительная таблица (таблица для Item имеет внешний ключ для группы).

• Если элемент может быть в нескольких группах - что, я полагаю, имеет место - тогда вы можете выбрать:

  • ассоциация "многие ко многим" .Каждая сущность (Item или Group) имеет список сущностей другого вида.
  • a квалифицированная ассоциация.Квалифицированные ассоциации обычно представлены HashMap (Date, Item) или, как вы, специальной коллекцией GroupItem.

ВВ двух последних вариантах вам понадобится дополнительная таблица для моделирования связи между Group и Item на уровне базы данных.

Answer 3

У каждого класса есть отдельная таблица, это хорошая сегрегация понятий. С этим методом вы можете использовать какой-нибудь инструмент ORM для хорошей архитектуры.

А также некоторые зрелые инструменты orm, такие как NHibernate , будут обеспечивать различные виды отображения классов, такие как наследование, композиция, отношение 1-1, отношение 1-многие и т. Д. Поэтому лучше использовать инструмент ORM для хорошая разработка, управляемая доменом