【问题标题】:What strategy: Custom LINQ or SQL queries stored in database什么策略:存储在数据库中的自定义 LINQ 或 SQL 查询
【发布时间】:2013-11-06 14:46:04
【问题描述】:

我正在开发的一个应用程序广泛使用 Linq to EF。它是多租户的,因此不同的客户将所有数据都存储在同一个数据库中。

一些客户想要自定义报告。理想情况下,这些自定义报告的定义将针对客户存储在数据库中,因为将这些报告硬编码到主代码中是不切实际的(很快就会失控)。

我过去通过存储 SQL 字符串解决了这个问题,然后使用context.SqlQuery(myReportSQL) 对其进行评估。它工作得很好。

两个想法:

  1. 目前客户无法编辑 SQL 字符串。它在内部进行管理,以避免运行错误类型的查询。你会如何建议向客户开放这个?查询构建器界面(欢迎对插件有任何建议)?只允许 SELECT 语句的东西?

  2. 更好的方法是使用 LINQ to EF 查询,因为:确保它只是一个 SELECT 更容易,我可以在最后链接额外的 WHERE 以确保它们只获得正确的数据,并且它更具可读性。

那么对于选项 2,您如何将其存储在数据库中,然后有效地“评估”它?

我已经看到 Dynamic LINQ 库在一定程度上有所帮助,但我担心它已经过时并且可能会被丢弃/不支持 EF6 等。

【问题讨论】:

  • 我想到了另一个想法:以某种 JSON 格式存储查询。有没有我应该遵循的标准?
  • 关于 1. 如果您向客户开放它,那么您将保护谁来保护客户不获取其他客户的数据?关于 2. 客户如何构建 LINQ 运行时?
  • 1.正是 - 这就是它的问题!必须非常仔细地解析/检查它。完全不热衷于此。一种解决方案是让他们从只包含他们被允许查看的数据的预定义查询中进行查询。
  • 还有 2 - 好吧,我想这是不可能的。因此我的问题在这里。也许我追求的是一种在内部解析的 linq 风格的语法。
  • 我不敢相信我会这么说 - 但你考虑过 Entity-SQL 吗?msdn.microsoft.com/en-us/library/bb399560.aspx

标签: c# .net asp.net-mvc entity-framework linq-to-entities


【解决方案1】:

我曾将动态 linq 用于类似目的,但同样担心未内置到框架中。这个想法是存储片段而不是一个大型查询。例如,如果您想显示父关系之外的列,您可以使用“Parent.Column”作为该列的表达式。在这方面,它的编写和维护比 SQL 简单得多,因为您不需要编写所有的连接等。

我们还有一个谓词的概念,您可以在其中存储一个表达式和一个运算符并传入一个值。例如,存储“Parent.Column”和“Equals”并在字典中传递值。例如字典["parentColumn"]

既然您提到这将用于报告,您是否考虑过使用允许您定义数据源并让您的业务用户创建自己的报告的 SSRS(SQL Server Reporting Services)?您可以通过不同地定义数据源来处理多租户。

【讨论】:

  • 这里的其他答案都很有用,但对我来说这是最好的方法。它提供了可以由客户指定的片段的安全性,然后以安全的方式连接在一起。它自然会导致一个 UI,您可以在其中从下拉列表中选择字段和谓词等或拖放。
【解决方案2】:

在多租户中,如何处理动态查询的安全性是困难的部分

我将从表值函数开始,您可以在其中硬编码客户 ID 的参数

用它来建立一些直接表和一些常见的连接

FUNCTION

视图具有安全性,但不幸的是,不允许您传递参数(据我所知),因此多个客户可以使用相同的视图。您可以看到为每个客户制作一个版本。

【讨论】:

    【解决方案3】:

    如果您要以任何格式存储查询,我会选择 SQL,因为这是执行任何数据库查询的最终形式,它是人类可读的,并且可以很容易地以纯文本形式存储格式。这当然正是数据库对存储过程和视图定义所做的事情,因此您也可以简单地使用数据库提供的工具并使用存储过程或视图定义。

    根据您的应用程序所使用的上下文,现有的数据库报告工具(例如 MS SSRS)将利用数据库安全性和查询功能以及提供部署平台。

    要回答有关如何打开查询以供用户修改的问题,您需要考虑各种问题:

    • 您的用户最愿意以何种形式修改查询(例如 SQL、图形查询构建器等)
    • 您需要实施哪些安全限制以确保用户只能访问适当的 DML 命令和授权数据(同样,数据库提供安全功能,因此请确保您没有重新发明轮子)
    • 您需要哪些版本控制工具来允许用户自定义查询而不影响其他用户

    然后决定您的方法并设计解决方案。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-08-29
      • 2017-11-15
      • 2019-11-01
      相关资源
      最近更新 更多