EF4 Poco问题映射类型相同名称相同程序集不同的命名空间

Ken*_*rdt 23 c# namespaces poco entity-framework-4

我遇到了EF4Proxy Pocos的问题.

我在同一个程序集中有两个具有相同名称的类但名称空间不同:

QuoteModels.CashPayment
OrderModels.CashPayment
Run Code Online (Sandbox Code Playgroud)

这编译很好但在运行时EF抛出以下异常:

指定的架构无效.错误:\ r \n由于多个CLR类型与EDM类型"CashPayment"匹配,因此CLR类型到EDM类型的映射不明确.以前发现CLR类型'QuoteModels.CashPayment',新发现的CLR类型'OrderModels.CashPayment'

是否有一种解决方法可以在具有不同命名空间的同一程序集中使用具有相同名称的类来与Ef4一起使用?

我是否必须给他们不同的名字或将他们移到另一个集会?

Jax*_*ian 12

我找到了解决办法.这是一个非常明显的解决方案,这是非理想的,但我想我会把它称为足够好,直到EF5出来解决这个问题.

简答:只需重命名一个或两个ambigous实体就像:2x Person被重命名为:Personal_Person并且Work_Person基于a PersonalContext和a WorkContext.

长答案:在我们的场景中,我们使用的是DB-first方法(我们用最少的DB更改重写遗留应用程序).我们的数据库包含数百个表,因此我没有使用单个EDMX/Context,而是使用多个EDMX /上下文(每当我尝试添加超过一半的表时,EDMX就会出​​现问题).但是,某些表需要存在于多个EDMX/Context中.

为了讨论,我们假设我们有一个包含以下表格的简单数据库:

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

另外,为了便于讨论,让我们假设存在于多个上下文中的任何表都会导致这个问题(正如我在Devart的回答中所说的那样,这不是真的,我不明白为什么它有时会起作用).

现在让我们说我们要创建两个上下文:

PersonalContext:

  • Person
  • Family
  • Relationship
  • Address

WorkContext:

  • Person
  • Business
  • Address
  • Employee

在这种情况下,无论是PersonAddress会造成我们的问题.那么我们在EDMX映射中要做的就是将我们的实体重命名为Personal_Person/ Work_PersonPersonal_Address/ Work_Address.

如上所述,这是一个非常明显的解决办法,这是非理想的,但由于EF不考虑名称空间并严格按名称(不是真实身份,只是名称),一个选项是将你的命名空间放在里面你的名字.

现在我还在争论,如果我要那样做,或者是为每个实体命名空间中的名称(Personal_Person,Personal_Family,Personal_Relationship,Personal_AddressWork_Person,Work_Business,Work_Address,和Work_Employee)的一致性和智能感知友好(保持所有实体在适当的字母顺序排列)实际上,命名空间属于名称之前而不是之后,但这是一个判断调用,对提供问题的解决方案并不重要.

我希望这有帮助!!


Dev*_*art 3

看看这篇文章。Derek的评论似乎涉及同样的问题,但他没有收到微软的任何答复。

  • 今天遇到这个问题,首先使用代码。在这种情况下,这个问题很愚蠢,因为代码本身非常清楚要使用哪种类型。看起来像是泄漏抽象的情况,其中代码优先 API 被猛烈地放在旧的 EF 之上。 (4认同)
  • 没有任何。我现在正在为此苦苦挣扎,需要找到解决方案。我的问题是,并非所有与此匹配的课程都会导致问题。这似乎只是由充当多对多关系的表引起的。例如,在您的场景中,如果“CashPayment”是存储财务信息的标准表,那么它对我来说按预期工作!但是,如果 `CashPayment` 只是一个指向 0 对多 `CashTransaction` 实体的多对多表(因此使 `CashPayment` 成为 `CashTransaction` 类型的集合),那么它就会在 `CashPayment` 上爆炸。桌子。合理? (3认同)
  • 他做到了:@Derek 这是故意的。您可以将 POCO 类放在您想要的任何命名空间中。实体框架按照约定检测实体上的哪些属性与模型中实体的属性相匹配的机制不使用命名空间。重要的是类型名称(不带命名空间)与模型(edmx/csdl 文件)中的 EntityType 名称相匹配。需要注意的一个方面是,是否有多个具有相同名称但位于不同命名空间中的类型。因为我们不考虑命名空间,所以我们检测到找到了多种类型并抛出异常。杰夫 (2认同)
  • 感谢您的澄清。知道他们为什么要这样做吗?未来这种情况会改变吗?我希望能够在同一个程序集中拥有 POCO,但不同的命名空间具有相同的名称,你知道吗? (2认同)
  • 有谁知道这是否已被报告为 MSDN Connect 上的错误?我的搜索没有找到任何结果,但我可能会错过它。无论 EF 团队是否认为这是一个错误,它都是一个错误。为什么有人希望通过 DbContext 类中指定的命名空间以外的命名空间进行 EF 随机监听?它违反了我对 C# 的了解。 (2认同)