Использование как ObjectContext, так и DbContext

Сценарий: попытка извлечь и переназначить информацию из одной базы данных в другую. В БД А есть данные, которые я хочу получить. Я хочу сохранить его в БД B в немного другой структуре.

DB A Я использую модель, созданную базой данных EDMX, поэтому она использует производную от ObjectContext. БД Б Я хотел бы, чтобы меня создал код. Поэтому я использую первый подход с кодом / моделью, устанавливая EntityFramework 4.1 через диспетчер пакетов. Итак, DB B использует производную DbContext

Когда я пытаюсь сохранить информацию из БД A в БД B, он говорит:

Метод тестирования RoutIT.Irma.Import.Service.Test.ImportIrma2ProductTests.ImportProducts вызвал исключение: System.ArgumentException: не удалось найти тип концептуальной модели для «Некоторый объект в модели EDMX БД А»

Фактически это происходит при добавлении объекта DB B к свойству DbSet Derived DbContext DB B. Итак, код похож на

using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
{
            foreach (FirstPVC pvc in pvcs)
            {
                this._irmaImport.FirstPVCs.Add(pvc); <--
                this._irmaImport.SaveChanges();
            }
            scope.Complete();
        }
 }

Это происходит в месте кода, отмеченном стрелкой вверху («‹ - »)

FirstPVC является свойством DB B, но в точке стрелки он жалуется на отсутствие концептуальной модели для объекта, принадлежащего контексту DB B.

Это странно, поскольку я пытаюсь сохранить объект DB B в контексте DB B. Почему он должен заботиться о сущностях БД A.

Все контексты содержатся в одном проекте. Но Derived DbContext DB B имеет информацию только о своих собственных свойствах DbSet ‹>, и внезапно при попытке добавить что-то в свойство DbSet‹> он выдает ошибку, выделенную жирным шрифтом выше.

Кто-нибудь знает, почему это происходит? Почему DbContext должен заботиться о сущностях другого контекста, в частности, об одном из производных классов ObjectContext.

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

[EdmEntityTypeAttribute(NamespaceName="Irma2Model", Name="AccessProvider")]
[Serializable()]
[DataContractAttribute(IsReference=true)]
public partial class AccessProvider : EntityObject
{
    /*****...... ******/
}

.net c# entity-framework dbcontext objectcontext
person boyke    schedule 10.08.2011    source источник
comment
Думаю, у меня такая же проблема. У меня было два EDMX, ориентированных на DB, отображающих разные таблицы из одной и той же БД, и теперь я переключил одну из них на новую модель EF4.1 DbContext / POCO. Тем не менее, когда я пытаюсь использовать последнее, я получаю сообщение об отсутствии модели для таблицы в другом EDMX. Может быть, этот ответ актуален ?: stackoverflow.com/questions/3521497/. Примечание. Я думаю, у вас есть опечатка в вашем сообщении, в котором жалуется на отсутствие концептуальной модели для объекта, принадлежащего контексту БД B, вы имеете в виду БД A, верно?   -  person zeroid    schedule 12.08.2011
comment
stackoverflow.com/questions/6899567/ это тоже. Хотя нет ответа   -  person zeroid    schedule 12.08.2011

Ответы (1)


arrow_upward
6
arrow_downward

Нашел ответ, но это не то, что вы хотите услышать:

http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/d2a07542-cb33-48ba-86ed-4fdc70fb3f1a

«Если вы используете генерацию кода по умолчанию для файла EDMX, то сгенерированные классы содержат ряд атрибутов, чтобы помочь EF найти, какой класс использовать для каждого типа сущности. EF в настоящее время имеет ограничение, что классы POCO не могут быть загружены из сборка, содержащая классы с атрибутами EF (краткий ответ - нет, ваши классы должны быть в отдельных проектах).

Это несколько искусственное ограничение, и мы понимаем, что это болезненно, и мы постараемся удалить его в будущем ».

Таким образом, обходным путем было бы разделить классы на две разные сборки.

person zeroid    schedule 12.08.2011
comment
Спасибо, что прыгнули в огонь на этом. Вы только что сэкономили МНЕ пару часов. В любом случае я хотел выделить классы edmx в отдельную сборку. Вы должны задаться вопросом, какие накладные расходы скрываются под прикрытием EF. Серьезно подумываю о следующем раунде nhibernate! - person drogon; 03.02.2012