3

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

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

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

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

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

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

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

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

请分享您的想法和意见。

4

1 回答 1

6

这两种选择都不是一个好的选择。

最终用户（理论上）精通业务逻辑——他们不应该需要精通编程语言来完成他们的工作。

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

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

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

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

  • 忽略数据
  • 按原样使用数据
  • 格式化数据
  • 在别处查找价值
  • 执行计算

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

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

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

这有意义吗？

于 2012-11-01T18:55:38.783 回答