2010-10-26 57 views
14

这纯粹是一个与EF4相关的概念和设计思想。在运行时修改实体框架模型

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

我知道EF有一些功能可以在运行时将模型推送到数据库,但问题是您是否可以使用EF来修改模型并实时更新数据存储?

换句话说,如果我为用户提供了添加用户定义列的机制,那么可以使用EF随时完成关联数据类型和空要求,然后记住所有未来会话?

它在那里,但我想你们都会看到我所得到的。

布伦特

+0

那么你结束了哪个解决方案? – Guillaume 2012-08-08 13:57:23

+0

我没有。从来没有能够测试或获得任何工作。无论如何,我最终在长远的运行中首先使用代码。 – 2012-08-08 15:40:46

回答

14

我以前被问过这个问题几次。没有明显或简单的方法。有可能没有办法,但我们是开发人员,总有办法!我知道那是什么吗?我可以想出一些想法吗? ....嗯..在运行时,该模型基于元数据工作空间中的强类型类。您可以即时创建这些内容。但是,你需要修改edmx文件的xml。有LINQ to XML或xpath。修改数据库模式...模型如何首先构建dbs ...它创建sql然后执行它。你必须创建sql(如何?耸肩)并执行它(objectcontext.executestorecommand())。可行?可能?我没有任何线索。真的,答案是否定的......就我所知,在VS或.NET 4(EF API)中没有任何东西可以很容易地实现这一点。肯定有人比我更聪明,更耐心地(浪费了??)很多时间(试图)超越智能EF来解决这个问题。然而,根据你对Jeremy的博客文章的建议,你正在寻找内置/方便的东西。用“nope”更容易回答。

朱莉

+7

欢迎来到SO,朱莉! – Yakimych 2010-10-26 07:24:38

+0

我在想'代码优先与'ExpandoObject'的组合可能会做到这一点。但是,不要让用户定义的字段具体化,反而把它们视为非标准的东西更有意义。 +1到Yakimych;欢迎! – 2010-10-26 12:17:32

+0

我同意用代码第一和NO模型会更容易,复杂性和规则少一层来处理但是很多工作 – 2010-10-26 13:30:38

1

杰里米米勒在this article讨论了类似的设置,。他使用nHibernate,但它可能会给你一些想法。

+0

是的,它给了我一些想法,其中没有一个是简单的。我很惊讶这个要求在nHibernate或EF上并不常见。任何其他资源或想法?没有真正回答刚提供参考的问题,很难为此解决问题。 – 2010-10-26 04:08:57

+0

我想过这样做,但我的方案意味着我必须允许用户在定义自定义字段之前首先添加“员工”......在某种意义上甚至表格是自定义的。 – War 2011-11-19 15:51:02

11

经常有解决问题的方法不止一种,这是不是一个例外。在这种情况下,您要查找的内容是允许用户向应用程序和数据库添加新字段,并使用应用程序内的这些字段。一些方法是:

a)允许用户修改数据库模式。
b)创建一个单独的结构来定义'用户定义字段'并在其中存储数据。
c)在用户更可能需要自己的字段的表中创建可为空的“保留”字段。

无论何时在应用程序中需要用户定义的自定义字段,我更喜欢(b)方法,有时(c)方法。下面是一些优点/缺点的每个三:

修改模式

风险:如果您允许用户修改数据库模式,你在哪里划清界线呢?如果他们可以添加字段,他们也可以改变现有字段的定义,添加或删除索引等。这可能导致支持梦魇,由用户完成架构修改触发的错误,性能问题等。
高性能:将新的用户定义字段内联存储在现有表中通常会比单独的结构具有性能优势,但只有在他们不会随着变化而过度发展。
Clunky:EF在设计阶段确定模式,因此要在运行时进行这项工作,您需要在运行时生成新的实体类,并使用代表新成员的成员来创建新的实体类,并且您需要更新映射元数据运行。运行时生成的实体类可以从设计时生成的类继承,因此您只需要为新的用户定义字段添加成员和映射。虽然可能,但它很笨重。使用运行时生成的类的代码需要使用反射来访问在运行时创建的新成员。

独立结构

用户界面友好:通过存储自定义字段创建一个独立的结构,您可以构建应用程序的逻辑,为用户添加/删除这些字段等,他们不需要与数据库混淆,相反,您可以在应用程序中添加维护表单以添加新字段。
EF友好型:无需在运行时混淆实体类和映射元数据。所有内容都是在设计阶段定义的,用户定义的字段只是数据。
性能稍差:使用单独的表来定义和存储用户定义的字段可能会使查找由于额外的往返或附加联接而稍微更昂贵。

Separate table structure for user defined fields

保留字段

往往不够:在许多情况下,自定义字段仅用于一个或几个额外的字段。预留几列将经常覆盖99%的用户需求。在LOB应用程序中,即使每个表中的通用“备注”字段也足够。
限制:如果用户需要比您保留的字段更多的字段,或者您保留的其他数据类型,那么这可能是一个限制。
高性能:列内联,检索时没有额外的往返或连接。
在设计时定义:没有运行时间与实体类型定义或映射混淆。

Reserved fields

0

这是来自@KristoferA的Reserved fields的一个版本,我过去曾经用过。

您可以在每个可能需要自定义数据的表上添加一个额外的XML(或JSON)列,然后使用EF从db读取/写入它。在读取反序列化XML(JSON)并将其传递给应该处理映射的机制之后,将其呈现给用户。写入从UI读取数据 - >映射到对象 - >序列化为XML(JSON) - >并写入这些额外字段也是如此。