我尽力提出一个合适的标题，如果它没有多大意义，可以找借口。我希望在下面更好地解释它。我们有一个基于.Net框架的应用程序，并使用SQL作为数据存储。与任何应用程序一样，此应用程序需要支持可扩展性，例如支持其他数据转换和扩展。验证。
示例：将应用程序视为提供一组输入表的工具，用户可以使用access或excel（已有UI和网格）导入数据以允许数据导入。导入数据后，该工具会创建一个中间模型，并对输入数据执行一些计算，然后以预定义的格式抛出结果。输入表模式和中间模型模式是固定的，不会发生任何更改。在从输入数据导出中间模型的阶段需要可扩展性。允许用户能够更改数据的派生方式，例如，不是按一个字段分组，而是允许按多个字段进行分组等。
为了支持这种灵活性，我发现我有两种基本方法可以看到
选项1：创建映射到sql数据模型的业务模型，并将业务模型公开给用户，以允许它们覆盖转换＆amp;创建新的转换（例如，使用LINQ或普通C＃）
选项2：公开整个sql数据模型，并允许用户嵌入原始SQL查询以执行转换＆amp;验证
我个人的偏好是使用选项1，因为我不是允许用户直接使用底层数据表的忠实粉丝。我更喜欢更有控制的访问。但是，这种方法要求用户使用编程语言（C＃或VB）。另一方面，选项2可能只需要具有SQL编程知识的人来创建原始查询并直接将它们插入应用程序。但是，我认为这是一个糟糕的方法。
产品管理团队倾向于使用选项2，因为他们认为从资源的角度来看它更灵活，更容易实现。
所以，我试图找出两种方法的优点和缺点，以更好地支持我对选项1的倾向。基本上，倾向于在C＃或VB .net中使用编程语言而不是仅仅使用纯SQL查询
请分享您的想法和意见。
答案 0 :(得分：6)
这两个选项都不是很好。
最终用户（理论上）精通业务逻辑 - 他们不需要精通编程语言来完成他们的工作。
你应该做的是创建一个使用标准控件扩展内容的框架 - 组合框，文本输入，网格等。如果没有具体说明你正在寻找什么样的可扩展性，很难给你具体的建议，但我我会举例说明我的项目：
我们的用户需要一种方法来向产品添加任意标签，以便在我们的网站上进行过滤。我们创建了一个数据网格，他们可以在其中输入类型的名称，指定它是“真/假”，整数，小数还是列表中的值，然后设置所述列表的项目。然后，在每个产品上，它们会显示所有适用类型的列表，并且需要填写值 - “True / False”生成一个复选框，整数和十进制生成文本字段进行验证，列表生成一个他们指定的所有选项的组合框。每当他们想要一个新的属性时，他们可以自己添加它，但他们不需要考虑这些属性是如何工作的，因为网站基于类型运行。
好的，根据你的例子，我建议：
提供一个表单，列出数据的每一列，并在其旁边有一个组合框，以指定要采取的操作。可以从包含以下内容的列表中选择操作：
根据用户在此下拉列表中的选择，您将：
String.Format选项的子集）。您将在底部显示一个键，以显示支持的值。对于“其他”查找，这可能主要是值和字符串的列表来转换它。这些值可以在应用程序的配置部分中指定，并存储在某个表的某个表中。您可以创建它们的任意分组以表示选项的各种“列表”。或者，您可以列出一些您希望用户引用的现有数据表，并让它们指定转换（使用计算屏幕）将其值转换为另一个表上的查找。
这有意义吗？