在代码中或应用程序加载时刷新/重新创建 EF 对象上下文
有没有办法在代码中执行在添加新项目下创建对象上下文时所做的操作 --> Visual Studio 中的实体数据模型？
比方说，我向数据库添加了一个新表。下次我加载使用该数据库模型的应用程序时，它会刷新模型并自动为该新表创建默认概念映射。
我可能会使用 ESQL 来查询数据库而不是 LINQ-To-Entities，因此我不关心是否存在对新实体集/对象的强类型访问。
另外，此解决方案首先需要 EF 代码吗？
Is there a way to do, in code, what is done when creating an object context under add New Item --> Entity Data Model in visual studio?
Lets say for instance I add a new table to my database. Next time I load the application that uses a model of that database, it refreshes the model and creates a default conceptual mapping for that new table automatically.
I would probably be using ESQL to query the database rather than LINQ-To-Entities, so I dont care if there is strongly typed access to the new Entity Sets / Objects.
Also, would this solution require EF code first?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的观点是，带有 EDMX 的 EF 尚未准备好应对这种情况。让我澄清一下原因：
ObjectContext只能使用这些文件中提供的实体。DefiningQuery只是数据库查询 - 您可以使用数据库（甚至另一个数据库）中存在的任何表，因为 EF 只对此查询的结果集感兴趣。使用代码优先，您将获得更好的开发体验。 Code First 不需要 EDMX 文件 - 它使用由代码定义的映射。您将需要您的应用程序在引导时从预定义（或所有引用的）程序集中收集从
EntityTypeConfiguration派生的所有类型。创建第一个上下文实例时，所有这些配置都将添加到OnModelCreation中的DbModelBuilder中。在重新启动应用程序并使用实体部署新程序集后，您将拥有一个可以轻松使用任何新实体的上下文。您仍然需要代码来使用这些实体。您必须手动创建 DbSet，而不是通过调用context.Set() 将它们公开为上下文类的属性。首先使用代码执行此操作会遇到一些问题，因为您必须关闭实体模型验证和数据库重新创建，并且必须自己保持所有同步。我们仍在讨论部署新程序集并且当应用程序重新启动时它将使用该程序集的场景。如果您需要从应用程序本身管理表和“实体”，那么这不是直接使用 ORM 的场景。对于某些元数据模型/多租户场景，它的完成方式完全不同，其中 ORM 用于某些通用抽象表，而真实实体是根据存储为抽象的元数据构建的。
My opinion is that EF with EDMX is not ready for this scenarios. Let me clarify why:
ObjectContextis able to work only with entities provided in these files.DefiningQueryis just database query - you can use any table present in your database (or even another database) because EF is interested only in result set of this query.With code first you will have much better development experience. Code first doesn't require EDMX file - it uses mapping defined by code. You will need your application to collect all types derived from
EntityTypeConfiguration<>from predefined (or all referenced) assemblies at bootstrap. All these configurations will be added toDbModelBuilderinOnModelCreationwhen creating the first context instance. You will have a context which can easily use any new entity after restarting application and deploying new assembly with entities. Still you will need code to use this entities. You will have to create DbSets manually instead of exposing them as properties on context class by callingcontext.Set<EntityType>(). There are some gotchas when doing this with code first because you must turn off entity model validation and database recreation and you must keep all in sync yourselves.Still we are discussing scenario where you deploy a new assembly and when application is restarted it will use the assembly. If you require managing tables and "entities" from the application itself then it is not a scenario for direct ORM usage. That is for some metadata models / multi tenant scenarios and it is done completely different way where ORM is used for some general abstract tables and real entity is constructed from metadata stored as abstraction.
为什么你真的想这样做？
我不知道有什么办法可以做到这一点。当您创建实体模型时，您实际上创建了一个基本上是 xml 的 edmx 文件。运行时你不能修改这些定义文件。 T4 模板从此 edmx 文件生成上下文和 .NET 类/实体。据我所知，您无法在运行时将类定义添加到模型/上下文中。
也许这篇文章也可以提供更多见解EF从未定义中检索实体表/视图。另外，我们希望 Ladislav Mrinka 或 Julie Lerman 加入这个问题；）
首先关于 EF 代码。这不会有任何区别，因为代码优先方法也是 edmx 文件/实体模型，但随后从中生成数据库（而不是从数据库生成实体模型），最终结果是相同的并且不起作用不同的运行时间。
Why do you actually want to do it this way?
I don't know a way to make this possible. When you create an entity model you actually create an edmx file which is basically xml. Runtime you can't modify these definition files. From this edmx file, T4 templates generate the context and the .NET classes / entities. As far as I know you can't add class definitions to the model / context at runtime.
Maybe this post also can give some more insight EF retrieve entities from undefined table/view. And else let's hope Ladislav Mrinka or Julie Lerman joins this question ;)
About the EF code first. That won't make any difference because the code first approach is also an edmx file / entity model but then generates the database out of it (instead of generating the entity model from the database) the end result is the same and won't work differently runtime.
嗯，.edmx 文件仅适用于 Visual Studio，不会成为应用程序的一部分。元数据存储在三个 xml 文件中，您可以在运行时加载它们：
http://blogs.msdn.com/b/alexj/archive/2010/01/27/tip-51-how-to-load-ef-metadata-from-an-任意流。 aspx
您必须将实体映射到类，这就是它变得丑陋的地方。类可以在运行时使用反射 API 生成。或者只采用一个具有许多属性的泛型类，例如 StringProperty1、StringProperty2。
SQL 比 ESQL 更适合您的目的。
学习EF：
http://www.testmaster.ch/EntityFramework.test
Well, the .edmx file is just for visual studio and won't be part of the application. The metadata is stored in three xml files and you can load them at runtime:
http://blogs.msdn.com/b/alexj/archive/2010/01/27/tip-51-how-to-load-ef-metadata-from-an-arbitrary-stream.aspx
You have to map the entities to classes and that is where it becomes ugly. Classes can by generated at runtime with the reflection-api. Or just take a generic class that has many properties like StringProperty1, StringProperty2.
SQL is more appropriate than ESQL for your purpose.
Learning the EF:
http://www.testmaster.ch/EntityFramework.test