动态查询的最佳选项
本文关键字：选项 最佳 查询 动态 | 更新日期: 2023-09-27 17:58:19
我正在将一个旧的应用程序从WebForms移植到MVC，这个过程的一部分是拆除现有的数据层，将逻辑从存储过程转移到代码。由于我最初只使用基本的C#SQL函数（System.Data.SqlClient），所以我使用了一个轻量级的伪ORM（PetaPoco），它只将SQL语句作为字符串并执行它。构建动态查询在SQL中的工作原理大致相同-许多条件添加和删除额外的代码（平均查询有大约30个过滤器）。
所以在环顾四周后，我发现了一些选择：
- 根据需要添加查询位的一组字符串和条件。真的很糟糕，尤其是当查询变得复杂时，如果有更好的解决方案，我不想追求这一点
- 使用L2E的一组条件语句。看起来更优雅，但我测试了L2E过于臃肿，总的来说是一种糟糕的体验。我能在L2S中做同样的事情吗？如果是这样的话，L2S会在未来5-10年继续存在吗
- 使用谓词生成器。仍在研究这一点，L2S也存在同样的问题
- 编辑：我也可以坚持现有的存储过程模型，但无论如何我都必须重写它们，所以考虑其他选项不会有什么坏处，因为我仍然需要做一些额外的工作
还有其他选择吗？有人能在上面提到的任何一种方法上积累一些经验吗？主要是，你选择的方法是否让你想要构建一台时间机器，并在实现它时扼杀了你？
我会看看LLBLGen。它生成的代码非常好并且可以自定义。它们还提供了一个强大的linq提供程序，可以帮助您进行查询。我用它做了几个大项目，非常高兴。
http://www.llblgen.com/
在我看来，L2S和L2E都无法生成高效的SQL代码，尤其是在涉及复杂查询时。即使在一些相对简单的情况下，通过这两种方法中的任何一种生成查询都会产生低效的SQL代码，下面有一个例子：为什么这种额外的联接会增加查询数？
也就是说，如果您使用SQL Server L2S是一个更好的选择，因为L2E意味着处理任何数据库；因此L2E将生成低效的SQL代码。另外需要记住的一点是，L2S或L2E都不会利用tempDB，即生成临时表或表变量或CTE。
我会重写存储过程，尽可能地优化它们，并使用L2S/L2E进行简单的查询，这将生成一个到服务器的往返行程（应该尽可能低），还确保SQL server使用的执行计划是最高效的（即使用索引等）。
Hasanain
不是一个真正的答案，但对于评论来说太长了：
我已经使用"连接SQL片段"方法构建了一个中型web应用程序，目前正在做类似的工作，但使用L2E。
我发现，有了一些自制力，sql方法的连接图片并没有那么糟糕。当然，使用参数化查询，不要试图将用户输入直接粘贴到SQL中。
不过，我一直在慢慢地对L2E方法产生好感。它为您提供了类型安全性，尽管您必须从使用SQL的方式"向后"做一些事情，例如WHERE X IN (...)构造。但到目前为止，我还没有击中L2E无法处理的任何东西。
我觉得如果其他人大量参与，L2E方法会更容易维护。
您是否有L2E的"膨胀"是一个问题的实际用例？还是只是一种普遍的不适感，你觉得这个框架在幕后做得太多了？
一开始我肯定有这种感觉（好吧，现在仍然如此），当然也不喜欢阅读生成的SQL（尤其是与我在上一个项目中手写的SQL相比），但到目前为止，我发现L2E非常好，只在实际需要时才访问DB。
另一个问题是您使用的DB，以及它的L2E绑定的最新程度。如果您使用的是SQL Server，那么没问题。不过MySql可能更脆弱。L2E的流畅性很大一部分来自于它与VStudio的良好集成，以及VStudi奥自动从数据库构建实体模型的能力。不确定对非MS DB后端的支持有多好。