0

我正在尝试为基于 ASP.Net MVC 的应用程序评估实体框架。我的公司向我们的客户提供了一个 SQL 数据库，我们为客户提供了更改此数据库的工具。他们添加自己的字段，修改现有字段（通常使它们更大），但他们不会删除我们提供的任何字段。他们也可以添加自己的表格。他们修改数据库和描述每个表/字段的元数据表以及每个字段的自定义验证信息。我们已经有了向数据库添加字段和填充元信息表的工具。例如，我们运送了一张名为“Patient”的表格。他们可以将自己的名为“LastVisitDate”的字段添加到此表中，然后他们在我们的 FieldDefinitions 表中使用元信息（例如 Label =“LastVisitDate”，

<fields>
    <Patient.LastName>
    <Patient.FirstName>
    <Patient.LastVisitDate> <!-- Added by customer -->
<fields>

基本上，每次我们的应用程序启动时，我都无法确定表结构是什么（有数百个这样的表，但为了清楚起见，我将它们排除在外）。

这样的场景可以使用实体框架吗？我会很感激这方面的任何方向。我不愿意动态构建 sql 查询来实现 CRUD 操作，但我不清楚如何使用 EF 来实现这一点。

谢谢

4

2 回答 2

0

根据您的要求，我认为 EF 不会对您有好处。EF 节省开发人员时间的最大优势是它允许您编写强类型的 LINQ 查询并使用 EF 框架将它们转换为 SQL 查询。

就您而言，我认为没有简单的方法可以做到这一点。因此，在您的情况下使用 EF 没有任何好处。

于 2012-04-11T19:41:47.653 回答
0

最大的问题是 EF 上下文要么生成类型（模型优先），要么针对您指定的类型（代码优先）工作。如果您能以某种方式成功地动态生成 ObjectContext/DbContext，那么这本身可能不是问题。问题是这会破坏你的代码库的其余部分。

在医疗环境或任何实体属性需要由用户自己不断更改的环境中看到EAV 模型并不少见。不知道你有没有考虑过这样的选择？请注意，这不是一个干净且简单的解决方案，但我认为它比您当前的解决方案更好（或更差），因为至少它不需要持续的模式更改。

如果架构中有不可变的部分（我希望有很多），那么您当然可以开始使用 EF。

于 2012-04-11T20:13:45.323 回答