我目前正在用 C# 构建一个查询构建器，它首先提示用户指定他们想在本地机器上查询哪个数据库。
因此，该程序允许将数据库“插入”到其中，而不是拥有许多带有始终使用的表的数据库。
因此，对于我的查询生成器来生成 SQL 语句，以字符串的形式输出和执行 SQL 语句是否更有意义，或者我可以使用实体框架？我没有使用实体框架的经验，但是据我所知，如果您有一个静态数据库，您知道其表和架构，那么使用 EF 会更有意义 - 而可能是用户在运行时指定的任何数据库-时间。
我目前一直在使用 SQL 语句——即用户与查询构建器的交互，实际上是执行应用程序生成的基于字符串的 SQL 语句。是否有可能或值得切换到实体框架？
根据我使用 EF 的经验，如果要动态生成查询，最好坚持使用 SQL 字符串。
使用 EF 查询未知模式的唯一方法是通过反射生成实体，这将是大量工作。而且我不确定它会起作用。而且，您将失去使用 EF 的所有好处。
所以，如果是这样的话，不。
实体框架在这种情况下不提供任何优势。事实上，它严格限制。
可以编写一个通用的 SortHelper、PagerHelper、FilterHelper 等，它将表达式树作为 IQuerable 并应用您想要的排序。这种泛型编程很棒，因为它避免了 SQL 注入。
但是，如果您使用实体框架作为查询生成器，则必须使用反射来生成实体数据模型。此外，您必须决定如何执行开放式选择语句。此外，您将依赖于 Entity Framework 如何表示和评估查询，这仍然不如 5.0 版的 ORM 应有的强大！例如，没有很好的方法来表示右连接，如果你想生成体面的 SQL，就必须始终将它们表示为左连接。另一个限制是，如果要编写投影，则需要生成一个匿名类。.NET 没有从内存中卸载类型的好方法，并且您在 AppDomain 中生成的每个类型都保存在内存中，直到 AppDomain 被卸载。这就是 F# 3.0 对其 F# 类型提供程序 API 使用类型擦除的原因，
此外，Entity Framework 不会进行任何类型的严肃分析来确定表达式是否可以转换，例如 SAT 求解。
我的答案基于现实生活经验，构建了您所描述的确切应用程序，然后是一些。该应用程序允许业务分析师以可视方式编写查询并将查询组合在一起。
也就是说，我确实建议学习 Entity Framework 的设计词汇。我已经转而使用非常相似的词汇，即使我不使用实体框架。例如，导航属性。我不称它们为属性，因为对于那些使用对象查询语言并且在可视查询语言中没有意义的人来说，这是一种面向对象的抽象。我称它们为路径。但我喜欢 Any() 运算符来暗示左连接，以及 Include()。那些小小的建模想法对我来说很有价值。