在代码中，有没有办法在 Visual Studio 中的 add New Item --> Entity Data Model 下创建对象上下文时做什么？
例如，我在数据库中添加了一个新表。下次我加载使用该数据库模型的应用程序时，它会刷新模型并自动为该新表创建默认概念映射。
我可能会使用 ESQL 来查询数据库而不是 LINQ-To-Entities，所以我不在乎是否有对新实体集/对象的强类型访问。
此外，此解决方案是否首先需要EF 代码？
问问题
725 次
3 回答
2
我的观点是带有 EDMX 的 EF 还没有为这种情况做好准备。让我澄清一下原因：
- EDMX 只是设计师使用的文件。在运行时，您需要从 EDMX 文件生成的 3 个 XML 文件（SSDL、MSL 和 CSDL）。这些文件定义了模型，它们是实体连接字符串的一部分。
ObjectContext只能使用这些文件中提供的实体。- 标准方法是每个连接/上下文一组这些文件。一旦您遵循标准方法，您就会非常困难，因为添加表意味着修改这些 XML 文件（您必须使用单独部署这些文件的方法 - 默认方法使用这些文件作为数据访问程序集中的资源）。
- 我描述了如何破解 EF 以允许每个连接多个文件，但我不推荐它。
- 如果您创建单独的元数据文件集，您将需要另一个上下文实例来处理新实体（另一个连接字符串），这两个上下文将不知道彼此，也无法使用映射到另一个上下文中的实体。
- 映射只是故事的一部分。现在您需要一个在应用程序中代表您的实体的类！如果您只希望这种“动态”行为仅用于开发，那么您可以，但是在运行时或重新加载应用程序时将表添加到模型中似乎不是一种方法 - 在 ORM 工具中定义模型是为了设计时间而不是运行时 = 你需要用您的新实体编译程序集，您需要一个代码来使用这些新实体并引用您的新程序集。
DefiningQuery只是数据库查询 - 您可以使用数据库（甚至另一个数据库）中存在的任何表，因为 EF 只对此查询的结果集感兴趣。
使用代码优先，您将获得更好的开发体验。代码优先不需要 EDMX 文件 - 它使用代码定义的映射。EntityTypeConfiguration<>您将需要您的应用程序在引导时收集从预定义（或所有引用的）程序集派生的所有类型。所有这些配置都将DbModelBuilder在OnModelCreation创建第一个上下文实例时添加。在重新启动应用程序并使用实体部署新程序集后，您将拥有一个可以轻松使用任何新实体的上下文。您仍然需要代码才能使用此实体。您将不得不手动创建 DbSet，而不是通过调用将它们公开为上下文类的属性context.Set<EntityType>(). 首先使用代码执行此操作时存在一些问题，因为您必须关闭实体模型验证和数据库重新创建，并且您必须自己保持所有同步。
我们仍在讨论部署新程序集的场景，当应用程序重新启动时，它将使用该程序集。如果您需要从应用程序本身管理表和“实体”，那么这不是直接使用 ORM 的场景。那是针对某些元数据模型/多租户场景，它以完全不同的方式完成，其中 ORM 用于一些通用抽象表，而真实实体是从存储为抽象的元数据构造的。
于 2011-06-18T14:21:06.333 回答
0
为什么你真的想这样做？
我不知道如何使这成为可能。当您创建实体模型时，您实际上会创建一个基本上是 xml 的 edmx 文件。运行时你不能修改这些定义文件。从此 edmx 文件中，T4 模板生成上下文和 .NET 类/实体。据我所知，您不能在运行时将类定义添加到模型/上下文中。
也许这篇文章还可以提供更多见解EF 从 undefined table/view 检索实体。否则，我们希望 Ladislav Mrinka 或 Julie Lerman 加入这个问题；）
先说EF代码。这不会有任何区别，因为代码优先方法也是一个 edmx 文件/实体模型，但是然后从中生成数据库（而不是从数据库中生成实体模型）最终结果是相同的并且不起作用不同的运行时。
于 2011-06-17T18:31:25.017 回答
0
好吧，.edmx 文件仅适用于 Visual Studio，不会成为应用程序的一部分。元数据存储在三个 xml 文件中，您可以在运行时加载它们：
您必须将实体映射到类，这就是它变得丑陋的地方。可以在运行时使用反射 API 生成类。或者只是采用具有许多属性的泛型类，例如 StringProperty1、StringProperty2。
SQL 比 ESQL 更适合您的目的。
于 2011-06-17T21:19:47.847 回答