В первом случае будет всего одна таблица (при схеме TPH).
В случае TPC таблиц будет столько, сколько и сущностей, не имеющих наследников.
Пример: Есть базовый класс «Клиент», у него наследники «Юр. лицо» и «Физ. лицо». В первом случае будет только одна таблица (TPH), во втором случае (TPT) будет три таблица, так сущностей три. А в случае TPC будет две таблица, т.к. конкретных сущностей всего лишь две: «Юр. лицо» и «Физ. лицо».
Суть в том, что приведение к классу наследнику не порождает подчиненных запросов, подтягивающих дополнительные данные. При инстанциации экземпляров сразу используется нужный тип и он заполняется всеми данными. По полиморфизму зачет.
Допустим, есть определенная иерархия классов. Entity Framework позволяет смаппить одну сущность на несколько таблиц. Для реализации наследования используют следующие схемы:
Table per Hierarchy. В этом случае вся иерархия помещается в одну таблицу, а поля сущностей маппятся на «свои» колонки таблицы, а в значениях остальных колонок содержится NULL.
Table per Type. При такой схеме БД, каждой сущности соответствует своя таблица. Плюсом является то, что БД нормализированная, но отсюда и минус, — при глубокой иерархии будет страдать производительность из-за джоинов.
Table per Concrete Type. В этот раз создаются таблицы для каждой ветки иерархии. И каждая таблица будет содержать поля промежуточных базовых сущностей.
А Вы уверены, что EF поддерживает «ленивую загрузку»? Ссылку в студию. Удивите!
Насколько я знаю, EF в отличии от LINQ2SQL ленивую загрузку не поддерживает. А разработчики EF обосновывают отсутствие оной необходимостью соответствовать ООП. А именно, при маппинге иерархии классов на таблицы БД, теперь можно приводить сущности к любому из базовых классов, на который есть маппинг.
И прежде чем воспевать дифирамбы EF проанализируйте производительность DAL, реализованных на ADO.NET, LINQ2SQL, EF, Active Record(NHibernate). Оченьудивитесь.
И по поводу «менять модель непосредственно в студии». Вы сами-то пробовали так изголяться, или начитались «умных» книжек по EF?
Так или иначе, но это уже «костыли», коих лишен IIS7.0
Кроме того, я не говорил, что проблемы нерешаемы. При достаточном доступе к настройкам сервера и определенном напряжением мозговых клеток можно добиться красивых урлов (и не только).
Проблем, по идее, не должно возникнуть при переносе на IIS 7.0 (только на Висте и на Win Server 2008).
А IIS 6.0 передает запрос на обработку конвееру asp.net по расширению, поэтому красивых урлов, как это предполагает технология не получится. Будут примерно такие mydomen/Home.mvc/About
А чтобы это победить нужно дополнительно устанавливать костыли в виде ISAPI_rewrite, etc. Если погуглить, можно найти примеры решений.
А если мы загрузили ColoredCar, то эта сущность приводится к базовому классу Car без инициализации дополнительных запросов.
А NULL-ы висят в таблице при реализации схемы TPH. Т.к. таблица всего одна, и записи в нее происходят и для сущности Car, и для сущности ColoredCar.
В случае TPC таблиц будет столько, сколько и сущностей, не имеющих наследников.
Пример: Есть базовый класс «Клиент», у него наследники «Юр. лицо» и «Физ. лицо». В первом случае будет только одна таблица (TPH), во втором случае (TPT) будет три таблица, так сущностей три. А в случае TPC будет две таблица, т.к. конкретных сущностей всего лишь две: «Юр. лицо» и «Физ. лицо».
Table per Hierarchy. В этом случае вся иерархия помещается в одну таблицу, а поля сущностей маппятся на «свои» колонки таблицы, а в значениях остальных колонок содержится NULL.
Table per Type. При такой схеме БД, каждой сущности соответствует своя таблица. Плюсом является то, что БД нормализированная, но отсюда и минус, — при глубокой иерархии будет страдать производительность из-за джоинов.
Table per Concrete Type. В этот раз создаются таблицы для каждой ветки иерархии. И каждая таблица будет содержать поля промежуточных базовых сущностей.
Насколько я знаю, EF в отличии от LINQ2SQL ленивую загрузку не поддерживает. А разработчики EF обосновывают отсутствие оной необходимостью соответствовать ООП. А именно, при маппинге иерархии классов на таблицы БД, теперь можно приводить сущности к любому из базовых классов, на который есть маппинг.
И прежде чем воспевать дифирамбы EF проанализируйте производительность DAL, реализованных на ADO.NET, LINQ2SQL, EF, Active Record(NHibernate). Оченьудивитесь.
И по поводу «менять модель непосредственно в студии». Вы сами-то пробовали так изголяться, или начитались «умных» книжек по EF?
Кроме того, я не говорил, что проблемы нерешаемы. При достаточном доступе к настройкам сервера и определенном напряжением мозговых клеток можно добиться красивых урлов (и не только).
А IIS 6.0 передает запрос на обработку конвееру asp.net по расширению, поэтому красивых урлов, как это предполагает технология не получится. Будут примерно такие mydomen/Home.mvc/About
А чтобы это победить нужно дополнительно устанавливать костыли в виде ISAPI_rewrite, etc. Если погуглить, можно найти примеры решений.