Может ли класс наследовать от класса Entity Framework и при этом сохраняться обратно в БД с использованием унаследованных сопоставлений классов?

#inheritance #entity-framework-4 #mapping #self-tracking-entities

#наследование #entity-framework-4 #сопоставление #самоотслеживающиеся сущности

Вопрос:

Может ли класс наследовать от класса Entity Framework и при этом сохраняться обратно в БД с использованием унаследованных сопоставлений классов? Я получал ошибки при попытке наследования от класса ‘Self-Tracking Entity’, когда я пытаюсь сохранить изменения, указывающие, что у типа нет никаких сопоставлений. Я бы надеялся, что, поскольку тип был унаследован от класса Entity, он также мог бы каким-то образом наследовать сопоставления entity, чтобы это сработало. Кто-нибудь смог заставить это работать?

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

Ответ №1:

Нет, это невозможно с EDMX (и объектами самостоятельного отслеживания). Если вы хотите сохранить производный тип, он также должен быть сопоставлен. Если вам нужно что-либо добавить в сгенерированный код, используйте свою собственную частичную часть класса entity.

Удивительно, но похоже, что это возможно с помощью code-first (EFv4.1 и DbContext API), но в таком случае вы не можете использовать объекты с самостоятельным отслеживанием. Я только что проверил базу данных, и это также невозможно с помощью code-first. Это автоматически создает TPH-наследование, а производный класс отображается как другая сущность.

Комментарии:

1. Это большой отстой. Это означает, что вы должны знать все производные классы заранее. В таком случае не удается добиться слабой связи объекта с EF.

Ответ №2:

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

 public partial class MyEntity
{
   //Extend the base object
   public string FormattedName
   {
      get
      {
         return String.Format("Lookie this! {0}/{1}", this.SomeString, this.SomeInt);
      }
   }
}
  

Редактировать — В ответ на ваше разъяснение, к сожалению, если вам нужно изменить класс EF в другой сборке, лучше всего создать класс-оболочку, который принимает класс Entity в качестве члена. Затем вы бы написали все новые функциональные возможности для доступа к общедоступным частям упакованной сущности. Это не даст вам постоянства для новых свойств, но вы все равно этого не получили.