EF4 Poco Issue Mapping Types Одно и то же имя Одна и та же сборка Различные пространства имен - PullRequest
Новая
       2

EF4 Poco Issue Mapping Types Одно и то же имя Одна и та же сборка Различные пространства имен

23 голосов
/ 28 июля 2010

У меня проблема с EF4 и Proxy Pocos .

У меня есть 2 класса с одинаковым именем в одной сборке, но разные пространства имен : 

QuoteModels.CashPayment
OrderModels.CashPayment

Это прекрасно компилируется, но во время выполнения EF выдает следующее исключение:

Указанная схема недействительна. Ошибки: \ r \ nОбображение типа CLR в EDM тип неоднозначен, потому что несколько CLR типы соответствуют типу EDM 'Наличный расчет'. Ранее найденный CLR введите «QuoteModels.CashPayment», недавно найден тип CLR 'OrderModels.CashPayment'

Есть ли обходной путь, чтобы классы с одинаковыми именами в одной сборке с разными пространствами имен могли работать с Ef4?

Должен ли я дать им разные имена или переместить их в другую сборку?

Ответы [ 4 ]

12 голосов
/ 02 августа 2010

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

Краткий ответ: Просто переименуйте одно или оба неоднозначных объекта. Например: 2x Person переименованы в: Personal_Person и Work_Person на основе PersonalContext и WorkContext.

Длинный ответ: В нашем сценарии мы используем подход, основанный на DB (мы переписываем устаревшее приложение с минимальными изменениями в DB).Наша БД содержит сотни таблиц, поэтому вместо использования одного EDMX / Context я использую несколько EDMX / Contextxts (EDMX квакает каждый раз, когда я пытался добавить более половины наших таблиц).Однако некоторые таблицы должны существовать в нескольких EDMX / Context.

Давайте обсудим, что у нас есть простая база данных со следующими таблицами:

  • Person
  • Family
  • Relationship
  • Address
  • Business
  • Employee

Кроме того, ради этого обсуждения давайте предположим, что ЛЮБАЯ таблица, которая существует в нескольких контекстах, вызывает эту проблему (как я уже говорил в комментариях к ответу Деварта, это не совсем так, и я не понимаю, почему это иногда работает).

Теперь предположим, что мы хотим создать два контекста:

PersonalContext:

  • Person
  • Family
  • Relationship
  • Address

WorkContext:

  • Person
  • Business
  • Address
  • Employee

В этом сценарии и Person, и Address вызовут нашу проблему.Итак, что мы будем делать в нашем отображении EDMX, это просто переименовать наши сущности в Personal_Person / Work_Person и Personal_Address / Work_Address.

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

Теперь явсе еще спорят, собираюсь ли я сделать это таким образом или, возможно, именовать пространство для каждой сущности (Personal_Person, Personal_Family, Personal_Relationship, Personal_Address и Work_Person, Work_Business, Work_Address иWork_Employee) как для согласованности, так и для Intellisense-содружественности (сохраняя все сущности в правильном алфавитном порядке), так как на самом деле пространство имен принадлежит перед именем, а не после него, но это суждение и не очень важно для решения проблемы.

Надеюсь, это поможет !!

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

Взгляните на этот пост .Кажется, что комментарий Дерека касается той же проблемы, и он не получил никакого ответа от Microsoft.

0 голосов
/ 15 января 2013

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

Пример: 

namespace Namespace1
{
 class Talk
 {
  public int TalkId {get; set;}
 }
}
namespace Namespace2
{
 class Talk
 {
  public int TalkId {get; set;}
  public string SomeExtraInfo {get; set;}
 }
}

Результат: 

namespace Namespace1
{
 class Talk
 {
  public int TalkId {get; set;}
 }
}
namespace Namespace1
{
 partial class Talk
 {
  public string SomeExtraInfo {get; set;}
 }
}

Надеюсь, это кому-нибудь поможет

0 голосов
/ 14 июля 2011

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

В одной из моих моделей у меня были следующие объекты («->» обозначает отношение с направлением): Users -> Authentication -> Authorization (пользователь проходит проверку подлинности, затем авторизуется).

С другой стороны, у меня были следующие сущности: Authentication -> Authorization -> InvoiceGeneration (авторизованный и авторизованный пользователь генерирует счет).

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

Оказалось, что моя проблема исчезла, когда я удалил сущность Authentication из второй модели, поэтому кажется , что преобразователь EDM в CLR не может справиться с сущностями, которые имеют "родителя" отношения (на обеих моих моделях Authorization "предшествовал" Authentication. Извините за описание ненаучных отношений:)

...