Полезно ли использовать NHibernate <join> из частичного класса «многие-ко-многим»?

Question

У меня есть Shop стола, StaffRole столик и ShopStaffRole стола, который служит многим-ко-многим, но с дополнительными полями, как IsRequired и т.д.

Так что мой выбор, кажется, Shop класса и класс StaffRole с NHibernate many-to-many, отображающий между ними, но который не будет отображать IsRequired в моей объектной модели, поэтому имеет смысл иметь класс ShopStaffRole, а также one-to-many сопоставления между ним и Shop и StaffRole.

Однако при ближайшем рассмотрении таблица StaffRole имеет только идентификатор и имя. Имеет смысл просто использовать NHibernate join, чтобы поместить StaffRoleName непосредственно в класс ShopStaffRole в качестве строки и покончить с представлением таблицы StaffRole как класса в целом?

Я не предвидеть StaffRoleName изменений в этом приложении, поэтому я должен быть в состоянии уйти с отображением только для чтения, что предотвращает один ShopStaffRole от воздействия на других с тем же StaffRoleName.

Имеет ли это смысл, или я что-то упускаю? Мне кажется, что моя объектная модель просто подбирает мою реляционную модель, таблицу за столом.

Answer 1

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

В моем случае я понял, что, хотя это приложение не нужно будет беспокоиться об изменении StaffRole, будет другая таблица, которая нашла свой путь в области позже по ссылке StaffRole, так что, если бы мы когда-либо хотели найдите «StaffRole of the Shop», затем просмотрите все учебные материалы, необходимые для этого StaffRole, тогда было бы хорошим способом иметь двухсторонние аксессоры между StaffRole-ShopStaffRole и StaffRole-TrainingStaffRole.

Answer 2

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