我需要提供一个小型应用程序，允许客户端针对其本地数据库创建查询（或“规则”）并触发某些操作（发送邮件、短信和其他内容）。
由于他们将被允许为这项工作陈述实际的 SQL，我想知道我的数据层应该是什么样子。似乎我不需要实体和存储库，因为所有数据交互都是弱类型的。
那么我的数据层应该做什么呢？打开连接，接受输入的SQL，返回属性包列表？我什至需要一个数据层吗？
[更新]
这是客户希望在他的应用程序中拥有的，能够针对他们的数据库编写或构建查询。它将在他们的本地计算机上运行，这意味着恶意员工不需要 SQL 注入攻击。
但是即使我有一个可视化控件来构建查询、验证和清理它，这一层的最终结果是 SQL 代码，不是吗？如果我想测试它，我该如何抽象它？
实际上，我们在 10 多年前遇到了几乎相同的问题（尽管它不在本地数据库中）。恕我直言，对于即席 SQL 查询（无论它们是如何创建的，用户可以只使用文本外壳来输入它们），DAL 没有多大意义 - 对于应用程序的通用报告/查询部分。这并不意味着您不能对应用程序中数据被修改或输入数据库的部分使用 DAL。
但是，您应该注意一些事情。显然，语法错误的查询应该给出有意义的错误消息，并且应该有可能中断长时间运行的查询。
限制对某些表的即席查询访问，或提供某些视图层，以将数据模型的技术部分隐藏在用户之外，这也是一个好主意。而且我会避免让您的用户以类似的临时方式修改任何数据 - 确保他们不能将任何 UPDATE 语句注入他们创建的 SELECT 语句中。
SQL通常，直接从用户接受查询或对查询的任何输入被认为是危险SQL的，因为这样的代码容易受到SQL Injection攻击。相反，如果这不是一次性案例，并且您希望让您的用户能够灵活地查询任何内容，您应该定义一种中间语言，用户将使用它来指定他们的过滤条件，这将用于SQL 查询生成。这样，你有
我们在我们的一个项目中这样做是为了让用户能够灵活地对底层数据模型的任何属性进行过滤、排序和分组，这种方法非常有效。
使用 PL/SQL 或更好的 ETL 工具构建报告数据库/星型模式，这将允许您清理/丰富数据，预先应用业务规则，使用列和表的业务语言而不是技术术语，并使用户查询返回快速，并将像 Cognos 这样的报告工具放在星型模式上，该模式为用户预先加入所有表，并允许您应用治理规则来防止用户犯傻。
这是最简单、最有效的方法，但并不便宜。