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