正确的模型用于MVC中的灵活调查

时间:2012-10-10 17:36:38

标签: asp.net-mvc model-view-controller

我正在寻找创建MVC应用程序来编辑各种客户调查的结果。但我正在努力让方法/模型在我的脑海里。

我有调查结果存储在不同的数据库表中(每个版本的调查一个表),每个版本的列集略有不同。我创建了一个组合(Sql)视图,它只显示了我想编辑的表列,因为源表包含许多不相关的列。

  

创建视图[vw_CombinedSurveyResults] AS

     

将'V10_v2'选为aTable,UniqueRecordID,ddDate,iIncidNo,bA,bB,bC,null为'bD   来自V10_v2

     

UNION   将'10_v1'选为aTable,UniqueRecordID,ddDate,iIncidNo,bA,bB,null为bC,bD   来自V10_v1

     

UNION   将'V9_v6'选为aTable,UniqueRecordID,ddDate,iIncidNo,bA,null为bB,null为bC,bD   来自V9_v6

我的第一个想法是搜索组合(sql)视图(按日期和事件编号过滤),然后在表格中显示结果,到目前为止一直很好。

我正在进行大脑冻结的部分决定如何最好地更新选定的个人调查记录是一种干净整洁的方式,并且在创建调查的未来版本时需要付出最少的努力

到目前为止,我已经为每个源表创建了一个sql视图(缩减为只有我感兴趣的列)并使用这些视图为每个源切换创建一些Linq To Sql类 - 下来的意见。 (这些是'模型')

我使用其中一个自动生成的类作为模型a来创建强类型视图以编辑调查值(只有一个版本,v10_v2)。

我有一个用于更新缩减视图的控制器(V10_v2)并且一切正常......但这仅适用于一个证明概念的调查版本,但它非常笨重。

继续沿着这条路走下去意味着我需要创建多个(MVC)视图和控制器,每个调查表一个,但必须有一个更流畅/更简单的方式来组织模型或视图,或两者兼而有之? p>

提前感谢任何建议。

1 个答案:

答案 0 :(得分:1)

你可以用不同的方式分解表格......

Surveys
-------
Id
Name
...

Fields
------
Id
SurveyId
Name
DataType

Answers
-------
Id
SurveyId
UserId
...

IntegerValues
-------------
Id
FieldId
AnswerId
Value (INTEGER)

StringValues
------------
Id
FieldId
AnswerId
Value (VARCHAR)

通过这种方式,一切都非常灵活,您最终会得到每种数据类型的表格,因此可以以强类型的方式访问它。您需要switch / select case语句来确定要根据字段定义查询哪些值

Re:Viewmodels

这里有很多选择......

首先,您可以创建多个模型,这些模型从公共字段模型继承,每个数据类型一个。然后,您的问卷调查视图模型看起来像......

Public Class QViewModel
    Public Property QuestionnaireId As Integer
    Public Property Fields As List(Of QField)
    ...
End Class


Public Class QField
    Public Property FieldName As String
End Class

Public Class QFieldInteger
    Inherits QField
    Public Property Value as Integer
End Class

Public Class QFieldString
    Inherits QField
    Public Property Value as String
End Class

这可以让您在创建代表问卷时为模型添加任意数量的QFieldstringQFieldInteger等等。如果您需要其他字段类型,也可以添加自定义编辑器(例如,一个映射到整数的多选答案,就像枚举一样)

或者,您可以通过Reflection.Emit(快速,复杂)或CodeDOM动态地使用反射构建整个事物(在运行时较慢,使用简单) )。这意味着您可以为每个调查创建一个具有相应类型属性的抽象类。

后一种方法(Reflection.Emit / CodeDOM)设置起来比较复杂,但如果你想进一步调整一些东西,可以提供更大的灵活性(例如,你可以在定义时直接向类属性添加自定义验证属性班级)。您必须担心缓存实例化类,确保您生成的类无法被破坏(例如,某人将.Net代码存储在数据库中的字段名称中),使您的操作和方法处理动态生成的课程和其他一些东西。

如果你无法获得所需的控制,我建议你从多模型方法开始并切换。