Разработка приложений - таблицы базы данных и интерфейсы

Question

У меня есть база данных с таблицами для каждого объекта в системе. например PersonTable имеет столбцы PersonId, Name, HomeStateId. Существует также таблица для «справочных данных» (т. Е. Штатов, стран, всех валют и т. Д.), Которые будут использоваться для заполнения выпадающих списков. Эта справочная таблица также будет использоваться для того, чтобы HomeStateId PersonTable был внешним ключом справочной таблицы.

В приложении C # у нас есть интерфейсы и классы, определенные для сущности. например PersonImplementationClass: IPersonInterface. Причина наличия интерфейсов для каждой сущности заключается в том, что фактический класс сущности будет хранить данные по-разному в зависимости от стороннего продукта, который может измениться.

Вопрос в том, должны ли интерфейс иметь свойства для Name, HomeStateId и HomeStateName (которые будут получены из справочной таблицы). ИЛИ должен ли интерфейс не раскрывать структуру базы данных, т.е. НЕ иметь HomeStateId, а просто иметь Name, HomeStateName?

Answer 1

Я бы сказал, что вы на правильном пути, думая об именах свойств!

Смоделируйте свои занятия так же, как в реальном мире.

Забудьте шаблоны базы данных и соглашения об именах StateID и внешних ключей в целом. У человека есть город, а не cityID.

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

Answer 2

Любой путь приемлем, но у обоих есть свои плюсы и минусы.

Первый способ (сущности имеют идентификаторы) аналогичен шаблону ActiveRecord , где ваши сущности являются тонкими оболочками над структурой базы данных. Часто это гибкий и быстрый способ структурирования вашего уровня данных, потому что ваши сущности могут работать напрямую с базой данных для выполнения операций над доменом. Недостатком является то, что при изменении модели данных вашему приложению, вероятно, потребуется обслуживание.

Второй способ (сущности отражают больше структуры реального мира) более аналогичен более тяжелому ORM, подобному Entity Framework или Hibernate . В этом типе уровня доступа к данным ваша структура управления сущностями позаботится об автоматическом сопоставлении сущностей назад и вперед в базу данных. Это более четко отделяет приложение от данных, но может быть гораздо более сложным для работы.

Это большой выбор, и его не следует воспринимать легкомысленно. Это действительно зависит от требований и размера вашего проекта, кто будет его потреблять.

Answer 3

Это может помочь немного отделить дизайн.

Для каждой сущности используйте два класса:

• Тот, который имеет дело с операциями базы данных на объекте (где вы бы поместили идентификаторы)
• Тот, который является простым объектом данных (где у вас будут стандартные поля, которые на самом деле что-то значат)

Как упомянуто @womp, если ваша сущность будет сохраняться только в базах данных, настоятельно рассмотрите возможность использования ORM, чтобы не потерять свою собственную.