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