运行时数据库的 SQL 与实体框架答案

【问题标题】：SQL vs. Entity Framework for databases at run-time运行时数据库的 SQL 与实体框架
【发布时间】：2012-11-12 16:54:45
【问题描述】：

我目前正在用 C# 构建一个查询构建器，它首先提示用户指定他们想在本地计算机上查询哪个数据库。

因此，该程序允许将数据库“插入”到其中，而不是让许多数据库的表总是被使用。

因此，对于我的查询构建器来生成 SQL 语句，以字符串的形式输出和执行 SQL 语句是否更有意义，或者我可以使用实体框架吗？我没有使用实体框架的经验，但是据我所知，如果您有一个静态数据库，您知道其表和架构，那么使用 EF 会更有意义 - 而可能是用户在运行时指定的任何数据库-时间。

我目前一直在使用 SQL 语句 - 即用户与查询构建器的交互，实际上是执行应用程序生成的基于字符串的 SQL 语句。是否有可能或值得切换到实体框架？

【问题讨论】：

我认为 EF 的优势充其量在静态操作数据库中是有争议的。尝试在一组动态数据库上使用 EF 将是我的噩梦。
@gbtimmon - 感谢您的贡献 - 这就是我想知道的 :) 我开始考虑切换到 EF 的唯一原因是有人称我的程序为“原始”，因为它生成 SQL 语句而不是使用英孚。
@DotNET - 不要让其他人的技术偏执影响您的架构，尤其是您承认不太了解的架构。进行研究和/或概念验证，然后自行决定最适合您的情况。
@DStanley - 感谢您的意见！
@gbtimmon 噩梦！就是这个词！ =P

标签： c# .net wpf entity-framework ado.net

【解决方案1】：

根据我使用 EF 的经验，如果要动态生成查询，最好坚持使用 SQL 字符串。

您可以使用 EF 查询未知模式的唯一方法是通过反射生成实体，这将是大量工作。而且我不确定它会起作用。而且，您将失去使用 EF 的所有好处。

所以，如果是这样的话，不。

【讨论】：

我只会切换到 EF，如果它能让事情变得更整洁，并且通常更全面更有意义。如果没有，我会保持原样:)
如果您精通 SQL，我不确定您是否应该考虑使用 EF。我已经使用 EF 很多年了，现在我几乎要回到手动 SQL 了。只有上下文和对象状态管理功能让我受不了。 EF 侵入性太强，而且很难测试...
@LMB - 你能提供更多细节吗？你用过 POCO 和 CodeFirst 吗？您有什么具体的改进吗？确实，在使用 EF 时模拟 EF 和/或为 DAL 编写真正的单元测试很难（或者有时是不可能的）。
@Pawel 好吧，我可以写一篇关于这个的文章...... EF 非常适合在一天内运行一个小应用程序。但是如果你在做一个严肃的项目，你不能： 1-使用惰性查询； 2-让懒惰的导航属性进入你的BL； 3-让 IQueryable 进入你的 BL； 4-访问未在 BL 中加载的导航属性。更加严格的设计，实体是数据库类型，所以，永远不应该在 BL 或更糟糕的 UI 中知道。我大部分时间都使用 POCO 和 CodeFirst 一段时间。更好的策略 IMO 是在 DBMS 中设计数据库，然后将架构导入 EF。然后实现 BL 接口。只需几句话！
感谢您的反馈。我很感激。

【解决方案2】：

实体框架在这种情况下没有提供任何优势。事实上，它的限制很严格。

可以编写一个通用的 SortHelper、PagerHelper、FilterHelper 等，它将表达式树作为 IQuerable 并应用您想要的排序。这种泛型编程很棒，因为它避免了 SQL 注入。

但是，如果您将实体框架用于查询生成器，则必须使用反射来生成实体数据模型。此外，您必须决定如何执行开放式选择语句。此外，您将与实体框架如何表示和评估查询相关联，这仍然不如 5.0 版的 ORM 应有的强大！例如，没有很好的方法来表示右连接，如果你想生成像样的 SQL，就必须始终将它们表示为左连接。另一个限制是，如果要编写投影，则需要生成一个匿名类。 .NET 没有从内存中卸载类型的好方法，并且您在 AppDomain 中生成的每个类型都保存在内存中，直到 AppDomain 被卸载。这就是 F# 3.0 对其 F# 类型提供程序 API 使用类型擦除的原因，以避免为像 RDF 这样有数十亿“类型”的数据库生成十亿类型。

此外，Entity Framework 不会进行任何类型的严肃分析来确定表达式是否可以转换，例如 SAT 求解。

我的答案基于现实生活经验，构建了您所描述的确切应用程序，然后是一些。该应用程序允许业务分析师以可视方式编写查询并将查询组合在一起。

也就是说，我确实建议学习 Entity Framework 的设计词汇。我已经转向使用非常相似的词汇，即使我不使用实体框架。例如，导航属性。我不称它们为属性，因为对于那些使用对象查询语言并且在可视查询语言中没有意义的人来说，这是一种面向对象的抽象。我称它们为路径。但我喜欢 Any() 运算符来暗示左连接，以及 Include()。那些小小的建模想法对我来说很有价值。

【讨论】：

感谢您的详细回答，+1 :)