EF4 DB-first: подход TPH?

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

Работа с моделью EF4 DB-First с использованием LINQ-to-Entities с POCO, которые будут использоваться приложением MVC3.

У меня есть три лица Customer, CustomerAdress и поиск CustomerAddressType,

Customer             CustomerAddress                  CustomerAddressType
----------           ----------------                 -------------------
CustomerId (PK)      CustomerAddressId (PK)           CustomerAddressTypeId (PK)
LastName             CustomerId (FK)                  Description (Values: Mailing, Billing)
FirstName            CustomerAddressTypeId (FK) 
MiddleInitial        Address
....                 City
                     State
                     Zip
                     StartDate
                     EndDate

Как вы видете CustomerAddress имеет ФК CustomerAddressTypeId, который определяет, какой это тип адреса, то есть почтовый или биллинг.

Я бы хотел:

  • Есть возможность сделать что-то вроде этого: Customer.CustomerAddress.OfType<MailingAddress> получить коллекцию почтовых адресов для клиента.
  • Есть CurrentMailingAddress а также CurrentBillingAddress свойства, которые бы возвращали единственный экземпляр CustomerAddress.OfType<> с самым высоким StartDate а также EndDate в будущем.
  • Также было бы неплохо принять Address через Zip свойства и рефакторинг этих свойств в сложный тип Address,

Я попытался создать 2 унаследованных объекта от CustomerAddress (при условии, что это стратегия TPH [таблица-на-иерархию]): MailingAddress а также BillingAddress, CustomerAddressTypeId быть дискриминатором. Я сделал это в конструкторе моделей, и как только я попытался добавить вторую унаследованную сущность, он сказал мне, что свойства с этими именами уже существуют, и не позволил мне переименовать их в соответствии со свойствами первой сущности.

Есть идеи как это сделать? Пожалуйста, поторопитесь для меня:) Спасибо!!!

1 ответ

Решение

Это не так тривиально. TPH будет возможно, но вы должны поместить все свойства на базу CustomerAddress и получить две дочерние сущности, которые не будут содержать никаких свойств, потому что все свойства являются общими (= должно быть в родительской). Вы будете использовать CustomerAddressTypeId как дискриминатор, и из-за этого вы не сможете отобразить это поле как свойство объекта. Я также не уверен, можете ли вы иметь поле как в дискриминаторе, так и в сопоставлении ассоциаций (это действительно хорошая домашняя работа для меня). Если нет, вы не сможете отобразить связь между CustomerAddress а также CustomerAddressType,

И то и другое CurrentMailingAddress а также CurrentBillingAddress являются вычисляемыми свойствами, и они не являются частью отображения. Это зависит от вас, чтобы реализовать их логику в вашей частичной части Customer юридическое лицо.

Я не понимаю последний пункт с Zip и сложный тип.