Entity Framework 4.0 Создание новой сущности, производной от других сущностей - PullRequest
2 голосов
/ 29 июня 2010

В настоящее время у меня есть сложная установка отношения сущностей, основанная на моей структуре данных в SQL Server 2008.

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

У меня есть таблицы Address и AddressType, которые объединены по addressTypeID.Есть 2 AddressTypes, "Billing" и "Shipping".Я хотел бы иметь возможность создавать собственные объекты для выставления счетов и доставки.Я бы подумал, что могу просто унаследовать от объекта Address и добавить к нему условие для получения правильного типа, но это не так просто.

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

Цель состоит в том, чтобы создать настраиваемые сущности, которые содержат поля из других сущностей на основе критериев критерия ... почти так же, как для представленияSQL сервер.Буквально все примеры, которые я нашел в интернете, не дают четкого представления о том, как это сделать.

То, что я сейчас имею, - это таблица по типу бетона (я полагаю).Каждый раз, когда я пытаюсь это сделать, я кричу на меня, говоря, что все не сопоставлено и т. Д., И я сопоставляю их, а затем получаю новое сообщение об ошибке.Есть ли какие-нибудь хорошие тутуриалы, которые ясны?Я бы предпочел не погружаться в ssdl и т. Д., Поскольку они будут перезаписаны при перестройке моей модели.

отложенная загрузка отключена ... вот как я этого хочу.

Почему можно 't Я просто создаю новую сущность, копирую и вставляю поля и устанавливаю отображение таблицы?Я создал новый объект с именем BillingAddress, скопировал поля из Address и установил сопоставление таблицы .... затем я получаю сообщение об ошибке:

Ошибка 297 Ошибка 3033: проблема при сопоставлении фрагментов, начиная со строки 4525: EntitySets 'BillingAddresses 'и' Addresses 'оба сопоставлены с таблицей' Address '.Их первичные ключи могут конфликтовать.

Я также пытался наследовать от таблицы адресов .... ошибка: необходимо указать сопоставление для всех типов в Set Addresses

Ответы [ 2 ]

3 голосов
/ 29 июня 2010

Если я правильно понимаю вашу схему, у вас есть таблица Address со столбцом дискриминатора addressTypeID, который определяет, какой тип Адрес представляет эта конкретная запись.Одна таблица Address содержит записи обоих типов ... Биллинг и Отправка адресов.Если это так, то у вас на самом деле есть структура Table-Per-Hierarchy, или TPH, поскольку в иерархии классов одна таблица .

Вы упомянули, что думали, что имелиструктура типа «таблица на бетон» или TPC.Если бы это было так, то вашей базе данных потребовались бы таблицы ShippingAddress и BillingAddress, поскольку в TPC одна таблица на конкретный тип .

Вы должны иметьструктура кода, подобная следующей:

public abstract class Address
{
    // Common address properties
}

public class ShippingAddress: Address
{
    // Additional shipping-address specific properties
}

public class BillingAddress: Address
{
    // Additional billing-address specific properties
}

Затем вам потребуется сопоставить иерархию классов типов ShippingAddress и BillingAddress как отображение TPH в вашей единственной таблице Address, различаемой наaddressTypeID столбец.Столбец AddressType даже не будет играть роль в отображении, если вы не хотите отображать по какому-либо имени AddressType или суррогатному ключу.В этом случае представление, представляющее объединенное представление соответствующих таблиц Address и AddressType, будет вашим базовым источником схемы TPH, а столбец дискриминатора будет столбцом суррогатного ключа, включенным в таблицу AddressType.

0 голосов
/ 29 июня 2010

На самом деле, это больше похоже на Таблицу на иерархию или, возможно, горизонтальное разбиение в концептуальной модели. См. эту страницу MSDN для (довольно скудной) документации по поддерживаемым архитектурам.

Если эта ссылка не помогает в достаточной мере, опубликуйте ваши точные определения таблиц и желаемый дизайн сущности (классы и свойства), и мы выясним это.

...