Я думаю, что вы спрашиваете: «Правда ли, что я не могу использовать связанную сущность в качестве поля дискриминатора для наследования таблицы на иерархию?» И это правильно. Вам понадобится отдельное поле дискриминатора, чтобы использовать таблицу для наследования иерархии. Однако в этом случае вам, вероятно, не понадобится сущность ResourceType, поскольку конкретного типа самой сущности достаточно, чтобы указать, какой значок использовать.
Однако я бы поставил вопрос: правильное ли у нас наследование?
Использование наследования в отображении O / R всегда является чем-то вроде компромисса, потому что вы будете использовать либо схему типа таблицы на иерархию, которая не отображается естественным образом в правильно построенную реляционную схему, либо схему типа таблицы на тип Это означает, что сервер БД должен работать усерднее, чтобы обслуживать даже простой список. Я думаю, что общая рекомендация по проектированию " композиция Favour по наследованию " еще более верна для O / R-отображений в частности, чем для OOD в целом.
Я понимаю, что изображения, которые вы добавили, являются просто примерами, иллюстрирующими ваш вопрос, и что ваш реальный дизайн может быть более сложным, но давайте использовать его в качестве примера:
Подтипы на диаграмме (Application, File и т. Д.) Имеют только одно свойство, которого нет в родительском типе. Для многих подтипов свойство "extra" является одинаковым, Link. У одного из них есть другое свойство (Filename), но я отмечу, что имена файлов могут быть выражены как URI.
В дополнение к дизайну наследования, который вы показали на иллюстрации, вы также можете смоделировать этот дизайн без использования наследования. В этом случае вы удалите подтипы, но сохраните сущность ResourceType.
Теперь давайте рассмотрим, как могут выглядеть некоторые примеры запросов для каждого дизайна:
// get books with inheritance:
var bi = from b in Context.RelatedResources.OfType<Book>()
select b;
// without
var bc = from b in Context.Resources
where b.ResourceType.ID == ResourceType.Book // static property you define on ResourceType
select b;
Никто не кажется мне ужасно плохим. Для меня это достаточная причина, чтобы не использовать наследование. Наиболее убедительным преимуществом наследования в отображении O / R является возможность легко извлекать объекты разных подтипов в одном списке. Но вы уже можете сделать это с этим дизайном. Поскольку проект композиции проще в реализации, менее сложен и будет использовать вашу базу данных более эффективно, я бы предпочел его, если нет явного преимущества наследования, которого я здесь не вижу.