动态查询的最佳选择？
|
我正在努力将旧的应用程序从WebForms移植到MVC，该过程的一部分是删除现有的数据层，将逻辑从存储过程转移到代码。因为最初我只使用基本的C＃SQL函数（System.Data.SqlClient），所以我使用了轻量级的伪ORM（PetaPoco），它仅将SQL语句作为字符串并执行它。建立动态查询在SQL中的工作原理几乎相同-许多条件条件会添加和删除其他代码（平均查询具有约30个过滤器）。
因此，环顾四周后，我发现了一些选择：
一堆字符串和条件，可在需要时添加查询的位。真的很讨厌，尤其是当查询变得复杂时，如果存在更好的解决方案，我就不想追求。
一堆使用L2E的条件句。看起来更优雅，但我测试过L2E太肿，总体而言是一次糟糕的体验。我可以在L2S中做同样的事情吗？如果是这样，那么L2S会在接下来的5-10年内持续存在吗？
使用PredicateBuilder。仍在研究有关L2S的相同问题。
编辑：我也可以坚持使用现有的存储过程模型，但是无论如何我都必须重写它们，因此，我仍然需要做一些工作，所以看看其他选项也不会有什么坏处。
还有其他选择吗？任何人都可以对任何一种提到的方法都具有一定经验的人-主要是，您选择的方法是否使您想要构建时间机器并杀死您来实现它？
没有找到相关结果
已邀请:
3 个回复
烫珊
贸会
诉嘎归亮
构造。但是到目前为止，我还没有遇到L2E无法处理的任何问题。 我觉得如果其他人大量参与，L2E方法将更易于维护。 您是否有L2E的“膨胀”有问题的实际用例？还是您觉得框架在幕后做得太多呢？ 一开始我肯定有这种感觉（好吧，还是这样做），当然也不喜欢阅读生成的SQL（尤其是与上一个项目中的手写SQL相比），但是到目前为止，L2E在仅在实际需要时才击中数据库。 另一个问题是您正在使用什么数据库，以及它的L2E绑定是最新的。如果您使用的是SQL Server，则没有问题。 MySql可能会更加脆弱。 L2E的出色之处在于它与VStudio的良好集成以及VStudio从数据库自动构建实体模型的能力。不确定对非MS DB后端的支持程度如何。