我正在开发一个生成报告的应用程序，该报告基本上是标准 SQL 操作（按 A/B 分组的数据的总和/平均值，其中 X=Y 等）
查询的部分可以由用户在运行时定义。在实现时，原始数据位于 DataTable 中，我将查询参数“解析”为 linq 表达式（基本上查询操作数映射到 DataTable 列名）。它很漂亮，而且工作量不大，但我不完全确定为什么我不只是将数据放在 SQLite 表中，而只是使用实际的 SQL，而只是从用户的输入中创建查询字符串。
我知道这是相当广泛的，但是我现在是否缺少一些优势，因为下线可能证明 linq 是一个更好的实现选择？唯一想到的是，如果我出于某种原因想要从 DataTable 转移到我自己的类，我仍然可以使用 linq 来查询它们。
【问题讨论】：
"the only thing that comes to mind is that if I want to move beyond a DataTable to my own classes for some reason, I can still use linq to query them"
这本身就是一个很好的理由。您的应用程序从不直接绑定到 sql 中获得了一定程度的语言独立性。如果您选择更改数据存储/备份，您会更轻松。
假设您的解析代码是可靠的，那么您通过使用 LINQ 的应用程序代码获得的另一个优势是它是强类型代码，并且比 sql 字符串更脆弱。
也许您没有考虑到这一点，或者它并不重要，但是通过公开 LINQ，您可以创建一个更友好的层来使用。
按照建议，您可以将数据放入 SQLite 并仍然使用 LINQ。您可以获得实体框架和 LinqToSql 的连接器，然后还有像 dbLinq 这样的库。
如果您可以将动态查询解析为 linq，然后让 linq 提供程序将其转换为底层数据库代码，您就可以将应用程序从现在看起来不错但将来可能不合适的技术和基础架构选择中抽象出来。您已经说过您正在考虑切换到 SQLite。
与所有抽象一样，但这取决于您的优先级是什么以及您必须接受（或不接受）什么，这决定了额外的抽象层是否重要。
【讨论】：
听起来你已经有了一个很好的解决方案。
如果您想迁移到 SQLite，请考虑其他优势，例如保存到磁盘、事务等。
或两全其美：LINQ over Sqlite（我认为这是可能的？）
【讨论】：
您可以将数据表放入 SQLite 数据并使用实际 SQL。我个人认为，为此重构代码的唯一原因是内存占用。如果数据表很大（足够大，最终会出现在大对象堆中），那么您可能不想将其长时间保存在内存中。否则没有太多理由走这条路，对内存中的信息进行操作总是比从磁盘访问信息要快。否则，我认为没有理由删除您使用 LINQ 所做的工作并使用 SQL 和 SQLite 文件重做所有工作。
【讨论】：