我在 MVC3 Web 应用程序中使用 Entity Framework 4.1。我的任务是重写一个带有大约 200 多个表的数据库的遗留应用程序，这些表已经存在数据，因此采用 EF 的数据库优先方法。
我知道为整个应用程序创建一个巨大的 edmx 模型是一种不好的做法，但是经过数小时的研究，我无法确定如何前进的明确方向，因为我无法弄清楚如何重用公用表在多个模型中。但我想将我的模型分解成更小的、可管理的上下文。
当我在两个模型中放置一个公共表（如Users）时，项目抛出编译错误，形式如下：
“Project.Models.EntityX”类型已包含“EntityX_PropertyY”的定义
Microsoft 于 2008 年 9 月 17 日下午 5:18 发布
这个问题是设计使然。解决方法是将模型放在不同的文件夹中（对于 C# 和 ASP.NET 项目），或者设置自定义工具命名空间（对于 C# 和 VB 项目）。
这是08年的事了。我无法选择工作，我想知道是否有更好的方法来构建项目，以便我能够在多个模型中使用同一个表？
我们的团队为我们的项目浏览了所有这些帖子（约 600 个表）。我在这里的回答有一个很大的警告是我们还没有完成这个项目，所以并不是所有的学习都发生了。我只能提供我们到目前为止所学到的东西。
从本质上讲，您想要做的事情不可能以现实的方式（目前，据我所知）。
我们的要求是能够使用可视化设计器（不一定是 Visual Studio 设计器），并且不必在一堆自动生成的文件中进行破解（或创建工具来自动破解文件），因为这只是一个秘诀以多种方式应对灾难。
我们最终得到了两种可能的解决方案，并指出我们真正想要的是表的逻辑分组：
使用LLBLGen中的设计器（注意：不可免费用于商业用途），它可以在逻辑上将表分离成数据库的不同“视图”
将表格分成基于业务的子集（即销售、报告等），重叠的表格使用不同的名称重复，并且每个子域中可能有一组不同的列
在我们的测试阶段，我们真的很喜欢 LLBLGen 的设计师。然而，代码生成选项令人眼花缭乱（绝对是由程序员为程序员编写的），并且输出还有很多不足之处（在我第一次尝试时，它生成了无法编译的代码）。如果你愿意在你的项目中投入几美元并花一些时间进行测试，我仍然建议你自己尝试一下（有免费试用版）；就像我说的，设计师很好，在网上翻阅了一下，似乎有很多成功的故事。
不用说，我们选择了后一种解决方案。这对我们有用，因为在我们的业务模型中，当我们有一个“共享”表时，除了一个子域模型之外，该表是只读的，我们不担心在所有子域模型之间传播更改（即，我们只需要对来自每个子域的数据有一定的了解）。这对你来说可能不一样。如果您开始对底层架构进行重大更改，则会产生额外的维护开销，但由于您使用的是旧数据库，因此可能不会出现这种情况。我们认为将工具保留在我们现有的开发环境中是值得的。（注意：我们使用稍微修改过的 POCO 文本模板来自己生成实体类。如果不出意外，这部分是一个非常好的决定。）
我想说只有大约 200 张桌子，尝试将它们全部放入一个模型中，即使只是作为一个实验。你肯定会想用你最强大的开发箱来做这个......当我们使用我们的模型（EF 4.0）尝试这个时，我们不得不在过程中杀死它。
在阅读过程中，我们确实看到了一些关于直接在 Visual Studio 设计器中支持模型“视图”的传言。如果这存在，我们绝对会使用它。尽管如此，我怀疑这种功能已经被搁置了。与 100 表或更少的项目相比，200 表的项目绝对是小众，它们并不真正需要这样的功能。
一个简单的解决方案就是更改模型中的实体名称。
您可以将上下文添加为实体名称的前缀，它会解决您的问题。
如果您仍然愿意尝试，只需将其扔在那里，但是您是否尝试过将模型放入不同的组件中？
例如：MyProject.Data.Sales 中模型中的所有订单表 MyProject.Data.Customers 中模型中的所有客户管理等
由于它们位于不同的命名空间中，因此它们不会以这种方式发生冲突，您应该能够拥有任意数量的它们。当你想使用它们时，你只需要正确地引用它们。