Может ли LINQ to SQL столбца IsDiscriminator НЕ наследовать?

Question

Я разрабатываю свою базу данных и приложение LINQ To SQL ASP.NET.

Представьте, что у меня есть два типа страниц: обычный и корень. Некоторые страницы являются корнями. На некоторых страницах нет.

У меня есть таблица базы данных Страницы и базы данных корневой страницы таблица:

 Page 
     ---- 
    PK PageId 
     HtmlTitle 
     PageHeading 
     MetaDescription 
     IsRoot 

     RootPage 
     -------- 
FK PK PageId 
     FavIcon 
     StyleSheet 
     MasterPage 

Я думаю, что если в моем файл DBML я установил IsDiscriminator свойство столбца IsRoot, то мой класс корневой страницы наследует класс страницы ,

Я хочу, чтобы иметь возможность работать, как это в моем коде:

MyDataContext db = new MyDataContext(); 

var roots = from p in db.Pages 
      where p is RootPage 
      select (RootPage)p; 

Или так:

RootPage r = new RootPage(); 
r.HtmlTitle = "Foo"; 
r.FavIcon = "bar.ico"; 
... 
db.Pages.Add(r); 
db.SubmitChanges(); 

Может LINQ к SQL колонке IsDiscriminator быть обнуляемым или ложь? Будет ли это работать?

Answer 1

Проблема заключается в том, что вы пытаетесь разделить свой класс между двумя таблицами, RootPage и Page.

К сожалению, LINQ to SQL поддерживает однонаправленную наследование, поэтому это не сработает.

Вам необходимо объединить два определения таблиц и сделать поля, специфичные для RootPage, нулевыми. например

Page 
    ---- 
PK PageId 
    HtmlTitle 
    PageHeading 
    MetaDescription 
    IsRoot 
    FavIcon (Nullable) 
    StyleSheet (Nullable) 
    MasterPage (Nullable) 

Вы бы затем установить IsRoot быть дискриминатор и пометить класс как тип страницы по умолчанию и корневая страница как класс для значения дискриминатора «True».

Альтернатива, если вы не возражаете, что только что прочитанное будет состоять в том, чтобы сделать вид, который соединял две таблицы вместе и основывал классы на этом.

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