2009-03-26 3 views
0

Я использую структуру Entity Framework и имею структуру наследования с базовым Entity (назовем его Customer) и производным Entity, назовем его AccountCustomer. Разница заключается в том, что у AccountCustomer есть дополнительные сведения (например, условия оплаты и т. Д.), Хранящиеся в отдельной таблице в базе данных и, следовательно, дополнительные свойства в Entity.Литейные сущности Entity Framework в «неправильном» направлении

Я хочу, чтобы пользователи могли «продвигать» конкретного Клиента как AccountCustomer. Мне нужно сохранить один и тот же первичный ключ (составной ключ, видимый для пользователей и используемый в качестве ссылки на клиента).

В настоящее время я чувствую, что вызов хранимой процедуры для создания дополнительной записи в таблице учетных записей является единственным способом, но до сих пор мы не обошли платформу Entity Framework, поэтому предпочли бы избежать этой техники, если возможное.

Есть ли у кого-нибудь какие-либо решения Entity Framework?

ответ

4

Это один из сценариев «Пожалуйста, не делайте этого».

Вы думаете об этом строго в терминах таблиц, а не в объектно-ориентированных терминах.

Особый клиент - это особый клиент. Он никогда не меняется. Теперь его статус может измениться, или он может приобрести дополнительные AccountProperties, но он никогда не переходит от того, чтобы быть одним из видов (Клиент) к другому виду (AccountCustomer). Это просто не имеет смысла концептуально (общий плод не превращается в яблоко, не так ли? Он начинается как яблоко с одним статусом и заканчивается как яблоко с новым статусом), и это, безусловно, невозможно в объектно-ориентированном программировании .NET ... что сделало бы невозможным в ORM, как EF.

Поэтому, пожалуйста, подумайте о разумном способе концептуализации этого, что приведет к разумному способу выразить это в объектно-ориентированных терминах, что приведет к разумному решению EF.

+0

этот ответ - вид дерьма, вопрос хорош и до точки – Adaptabi

+0

Извините, если вам не нравится ответ. Тем не менее, вопросник предпочитает объектно-ориентированные решения на основе EF. Объект, меняющий свой тип, несовместим по духу и, возможно, фактически с объектно-ориентированным дизайном на основе EF. Факты в том, что они есть, ответ в том, что это такое. – yfeldblum

0

Я решил это путем работы.

  • нагрузки все связанные свойства навигации базового класса, в том числе себя

var customer = db.Customers.Include("whatever dependince you have").FirstOrDefault(u=>u.UserId == userId); // вы можете повторить это для всех ваших включает

  • Кэш навигационные свойства локального переменные, т.е. var profile = customer.Profile;
  • Удалить базовый класс на db.Customer.Remove(customer);
  • Создайте класс derrive var accountCustomer = new AccountCustomer();
  • Установите все свои свойства и свойства навигации из базового класса, т.е.

accountCustomer.UserId = customer.UserId;

accountCustomer.Profile = profile; // do the same for all of the properties and navigation properties from the base class

  • Добавить новый класс обратно в БД

this.Entry<T>(accountCustomer).State = EntityState.Added;

  • Вызов db.SaveChanges()

Вот и все!

Смежные вопросы