动态查询的最佳选择？

Question

我正在努力将旧的应用程序从WebForms移植到MVC，并且该过程的一部分正在撕掉现有的数据层，将逻辑从存储过程转移到代码。由于我最初只使用基本的C＃SQL函数（System.Data.SqlClient），因此我使用了轻量级的伪ORM（PetaPoco），它只将SQL语句作为字符串并执行它。构建动态查询在SQL中的工作方式大致相同 - 添加和删除其他代码的许多条件（平均查询有~30个过滤器）。

所以看了一下之后，我找到了一些选择：

• 一串字符串和条件，可根据需要添加查询位。真的很讨厌，特别是当查询变得复杂时，如果存在更好的解决方案，我不想追求的东西。
• A bunch of conditionals using L2E。看起来更优雅，但我测试L2E太臃肿一般是一个糟糕的经历。我可以在L2S中做同样的事情吗？如果是这样，L2S会在未来5到10年内继续存在吗？
• 使用PredicateBuilder。仍在研究这个问题，关于L2S的问题。
• 编辑：我也可以坚持现有的存储过程模型，但无论如何我都要重写它们，所以看看其他选项也不会有什么坏处，因为我仍然需要做腿部工作。

那里还有其他选择吗？任何人都可以通过任何提到的方法获得一些经验 - 主要是，你选择的方法是否让你想要建立一个时间机器并杀死过去实现它？

Answer 1

我会看看LLBLGen。它生成的代码非常好并且可以自定义。他们还提供强大的linq提供程序，可以帮助您的查询。我用它做了几个大型项目，非常高兴。

http://www.llblgen.com/

Answer 2

不是答案，但评论时间太长了：

我使用“连接SQL”方法构建了一个中型Web应用程序，目前我正在使用L2E进行类似的工作。

我发现通过一些自我控制，concatenate-pices-of-sql方法并没有那么糟糕。当然使用参数化查询，不要试图直接将用户输入粘贴到SQL中。

我一直在慢慢地对L2E方法表示赞赏。它为您提供了类型安全性，但您必须从使用SQL的方式“向后”做一些事情 - 例如WHERE X IN (...)构造。但到目前为止，我还没有遇到任何L2E无法处理的事情。

如果其他人参与其中，我觉得L2E方法会更容易维护。

您是否有实际使用案例，其中L2E的“膨胀”是一个问题？或者只是一种普遍意义上的萎靡不振，你觉得框架在幕后做得太多了？

我一开始肯定有这种感觉（好吧，仍然这样做），当然不喜欢阅读生成的SQL（特别是与我之前项目中的手写SQL相比），但到目前为止已经发现L2E相当不错在实际需要时只关注数据库。

另一个问题是你正在使用什么数据库，以及它的L2E绑定是如何更新的。如果您使用的是SQL Server，那么没问题。虽然MySql可能更加不稳定。 L2E的一小部分光滑来自于它与VStudio的良好集成，以及VStudio自动从数据库构建实体模型的能力。不确定对非MS DB后端的支持有多好。

Answer 3

在我看来，L2S和L2E都不能生成有效的SQL代码，特别是涉及复杂查询时。即使在一些相对简单的情况下，通过这两种方法之一生成查询也会产生效率低下的SQL代码，这里有一个例子：Why does this additional join increase # of queries?

话虽这么说，如果你使用SQL Server L2S是一个更好的选择，因为L2E意味着处理任何数据库;因为L2E会生成效率低下的SQL代码。还要记住的另一点是，L2S或L2E都不会利用tempDB，即生成临时表或表变量或CTE。

我会重写存储过程，尽可能地优化它们，并使用L2S / L2E进行简单查询，这将为服务器生成一次往返（这应该尽可能低），并且确保SQL Server使用的执行计划是最有效的（即使用索引等）。

Hasanain