在运行时修改实体框架模型

Question

这纯粹是一个与EF4相关的概念和设计思想。

示例/场景是一个大型ERP或CRM类型的系统，公司可能需要添加传统的“用户定义字段”来捕获其他数据。

我知道EF有一些在运行时将模型推送到数据库的功能，但真正的问题是，您是否可以使用EF实时修改模型和更新数据存储？

换句话说，如果我为用户提供了一种机制来添加用户定义的列、相关的数据类型和null需求，那么可以使用EF动态地完成这些操作，然后在以后的所有会话中记住这些吗？

它是存在的，但我想你们都会明白我的意思。

布伦特

Answer 1

这个问题在过去已经被问过几次了。没有明显或简单的方法。有可能没有办法，但我们是开发人员，总会有办法的！我知道那是什么吗？不是的。我能想出一些主意吗？....Mmmm..在运行时，该模型基于来自元数据工作区的强类型类。您可以在运行时创建它们。但是你需要修改edmx文件的xml，有LINQ to XML或xpath可以实现。正在修改数据库架构...model如何创建dbs...it，然后再执行它。您必须创建sql (如何创建？耸肩)和执行它(objectcontext.executestorecommand())。可行吗？有可能吗？毫无线索。实际上答案是否定的…据我所知，在VS或.NET 4 (EF API)中没有任何东西可以很容易地实现这一点。肯定有人比我更聪明更有耐心(浪费？？)花了很多时间(试图)智胜EF来完成这件事。然而，根据你对Jeremy博客文章的建议的回应，你正在寻找一些内置的/方便的东西。这更容易用“不”来回答。

朱莉

Answer 2

解决问题的方法通常不止一种，这也不例外。在这种情况下，您需要的是允许用户将新字段添加到您的应用程序和数据库中，并在您的应用程序中使用这些字段。实现这一目标的一些方法是：

a)允许用户修改数据库模式。

b)创建一个单独的结构，用于定义“用户定义的字段”并在其中存储数据。

c)在用户更有可能需要自己的字段的表中创建可空的“保留”字段。

每当应用程序中需要用户定义的自定义字段时，我更喜欢(b)方法，有时也喜欢(c)方法。以下是这三种方法各自的一些优缺点：

修改架构

·风险:如果您允许用户修改数据库架构，那么您应该在哪里划清界限？如果他们可以添加字段，他们也可能更改现有字段的定义，添加或删除索引等。这可能会导致支持噩梦，由用户所做的模式修改触发的错误，性能问题等。

·Performant:将新的用户定义字段以内联方式存储在现有表中，通常比单独的结构具有性能优势，但前提是它们不会过度更改。

·笨拙: EF在设计时确定模式，因此要使其在运行时工作，您需要在运行时生成新的实体类，并在运行时更新映射元数据。运行时生成的实体类可以继承自设计时生成的类，因此您只需要为新的用户定义字段添加成员和映射。虽然有可能，但它很笨拙。使用运行时生成的类的代码将需要使用反射来访问在运行时创建的新成员。

独立结构

·用户友好:通过创建单独的存储自定义字段的结构，您可以构建应用程序逻辑，供用户添加/删除这些字段等。他们不需要打乱数据库，相反，您可以在应用程序中使用维护表单来添加新字段。

·EF友好:无需在运行时处理实体类和映射元数据。所有内容都是在设计时定义的，用户定义的字段只是数据。

·性能稍差:使用单独的表来定义和存储用户定义的字段可能会由于额外的往返或额外的联接而使查找成本略高。

​

​

保留字段

·经常:在许多情况下，自定义字段只用于一个或几个额外的字段。保留几列通常可以满足99%的用户需求。在LOB应用程序中，即使是每个表中的通用“注释”字段通常也足够了。

·受限:如果用户想要比您保留的字段更多的字段，或者想要比您保留的更多的其他数据类型，那么这可能是一个限制。

·Performant:列内联，检索时不需要额外的往返或联接。

·在设计时定义:没有运行时干扰实体类型定义或映射。

​

​

Answer 3

布伦特今天在Twitter上给我发了个pinged (这篇文章已经过去两年了)，想看看有没有什么变化。EF仍然不支持此场景。然而，Rowan Miller有一篇有趣的文章，介绍了如何使用Code First http://romiller.com/2012/03/26/dynamically-building-a-model-with-code-first/实现这一点

这可能会，也可能不会做你需要的，但值得一看。