c# - 允许用户在应用程序中嵌入原始 sql 查询是一种好习惯吗？

Question

我尽力想出一个合适的标题，如果它没有多大意义，请原谅。我希望在下面更好地解释它。我们有一个基于.Net 框架并使用SQL 作为数据存储的应用程序。与任何应用程序一样，该应用程序需要支持可扩展性，例如支持额外的数据转换和验证。

示例: 将应用程序视为提供一组输入表的工具，用户可以使用 access 或 excel(已有 UI 和网格)将数据导入其中以允许数据导入。导入数据后，该工具会创建一个中间模型并对输入数据执行一些计算，然后以预定义格式抛出结果。输入表模式和中间模型模式是固定的，不会发生任何变化。在从输入数据派生中间模型的阶段需要可扩展性。允许用户能够更改数据的派生方式，例如允许按多个字段分组而不是按一个字段分组等。

为了支持这种灵 active ，我看到有两种基本方法

选项 1:创建映射到 sql 数据模型的业务模型并将业务模型公开给用户以允许他们覆盖转换并创建新的转换(例如，使用 LINQ 或纯 C#)

选项 2:公开整个 sql 数据模型并允许用户嵌入原始 SQL 查询以执行转换和验证。

我个人的偏好是使用选项 1，因为我不太喜欢允许用户直接使用底层数据表。我更喜欢更受控制的访问。但是，这种方法要求用户具有编程语言(C# 或 VB)。另一方面，选项 2 可能只需要具有 SQL 编程知识的人来创建原始查询并将它们直接插入到应用程序中。但是，我认为这是一个糟糕的方法。

产品管理团队倾向于选择选项 2，因为他们认为从资源的角度来看，它更加灵活且易于实现。

所以，我试图找出这两种方法的优缺点，以更好地支持我对选项 1 的倾向。基本上，倾向于使用 C# 或 VB .net 中的编程语言来完成工作，而不是仅仅使用普通的 SQL 查询.

请分享您的想法和意见。

Answer 1

这两种选择都不好。

最终用户(理论上)精通业务逻辑 - 他们不需要精通编程语言来完成他们的工作。

您应该做的是创建一个使用标准控件(组合框、文本输入、网格等)扩展事物的框架。如果没有具体说明您正在寻找哪种可扩展性，很难给您具体的建议，但我我会给你一个我项目中的例子:

我们的用户需要一种方法来向产品添加任意标签，以便在我们的网站上进行过滤。我们创建了一个数据网格，他们可以在其中输入类型的名称，指定它是“真/假”、整数、小数还是列表中的值，然后为所述列表设置项目。然后，在每个产品上，他们都会看到所有适用类型的列表，他们需要填写值——“真/假”产生一个复选框，整数和小数产生验证的文本字段，列表产生一个他们指定的所有选项的组合框。每当他们想要新属性时，他们可以自己添加，但他们根本不需要考虑这些属性如何工作，因为网站是基于类型运行的。

---

好的，根据您的示例，我建议这样做:

提供一个表格，列出数据的每一列，旁边有一个组合框来指定要采取的操作。可以从包含以下内容的列表中选择操作:

• 忽略数据
• 按原样使用数据
• 格式化数据
• 在别处寻找值(value)
• 执行计算

根据用户在此下拉列表中的选择，您将:

• 不在输出中包含该列
• 按原样使用数据。
• 提供一个按钮来打开一个表单，他们可以在其中根据数据类型格式化数据(可能使用 String.Format 选项的子集)。您会在底部显示一个键以显示支持的值。
• 提供一个按钮来指定“别处”是什么。 这可能是可扩展性最有用的地方，所以我将在下面再次解决它
• 提供一种输入适当计算的方法。

至于“其他地方”查找，这可能主要是用于转换它的值和字符串的列表。这些值可以在应用程序的配置部分中指定，并存储在某处的表中。您可以创建它们的任意分组来表示各种选项“列表”。或者，您可以列出一些您希望用户引用的现有数据表，并让他们指定一个转换(使用计算屏幕)以将其值转换为对另一个表的查找。

这有意义吗？