3

さまざまな顧客調査の結果を編集するためのMVCアプリケーションを作成したいと考えています。しかし、私はアプローチ/モデルを頭の中で正しく理解するのに苦労しています。

異なるデータベーステーブル（調査のバージョンごとに1つのテーブル）に保存されている調査結果があり、バージョンごとにわずかに異なる列のセットがあります。ソーステーブルには無関係な列が多数含まれているため、編集するテーブル列のみを表示する結合​​（Sql）ビューを作成しました。

CREATE VIEW [vw_CombinedSurveyResults] AS

SELECT'V10_v2' as anTable、UniqueRecordID、ddDate、iIncidNo、bA、bB、bC、null as'bD FROM V10_v2

UNION SELECT '10_v1' as anTable、UniqueRecordID、ddDate、iIncidNo、bA、bB、null as bC、bD FROM V10_v1

UNION SELECT'V9_v6' as anTable、UniqueRecordID、ddDate、iIncidNo、bA、null as bB、null as bC、bD FROM V9_v6

私の最初のアイデアは、結合された（sql）ビュー（日付とインシデント番号でフィルタリング）を検索し、結果をテーブルに表示することでした。

私が頭を悩ませているのは、選択した個々の調査記録を更新する最善の方法を決定することです。これは、調査の将来のバージョンが作成されるときに最小限の労力で済む方法です。

これまでのところ、各ソーステーブルのSQLビューを作成し（関心のある列だけを表示するように切り詰めました）、これらのビューを使用して、各ソース切り下げビューのLinqToSqlクラスを作成しました。 。（これらは「モデル」です）

これらの自動生成されたクラスの1つをモデルaとして使用して、調査値を編集するための厳密に型指定されたビューを作成しました（1つのバージョンv10_v2のみ）。

カットダウンビュー（V10_v2）を更新するためのコントローラーがあり、すべて正常に機能します…しかし、それは概念を証明する1つの調査バージョン用ですが、非常に不格好です。

このパスを続行するには、調査テーブルごとに1つずつ、複数の（MVC）ビューとコントローラーを作成する必要がありますが、モデルまたはビュー、あるいはその両方を整理するためのより洗練された/より簡単な方法が必要ですか？

提案を事前に感謝します。

4

1 に答える 1

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：ビューモデル

ここにはいくつかのオプションがあります...

まず、データ型ごとに1つずつ、共通のフィールドモデルから継承する複数のモデルを作成できます。次に、アンケートのビューモデルは次のようになります...

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

これにより、アンケートを表すためにモデルを作成するときに、モデルに任意の数の、などQFieldstringを追加できます。QFieldInteger他のフィールドタイプで必要な場合は、カスタムエディタを追加することもできます（たとえば、列挙型のように整数にマップされる多肢選択式の回答）

または、Reflection.Emit（高速、複雑）またはCodeDOM（実行時に低速、使いやすい）のいずれかを介して、リフレクションを使用して全体を動的に構築することもできます。これは、適切なタイプのプロパティを使用して、調査ごとに抽象クラスを作成できることを意味します。

後者のアプローチ（Reflection.Emit / CodeDOM）は設定がより複雑ですが、さらに微調整したい場合は柔軟性が高くなります（たとえば、クラスを定義するときにクラスのプロパティにカスタム検証属性を直接追加できます） 。インスタンス化されたクラスのキャッシュ、生成されたクラスが破壊されないようにする（たとえば、データベースのフィールド名に.Netコードを格納する誰かによって）、アクションとメソッドに動的に生成されたものを処理させるなどのことを心配する必要があります。クラスや他の多くのもの。

複数モデルのアプローチから始めて、必要なコントロールが得られない場合は切り替えることをお勧めします。

于 2012-10-10T17:46:51.513 に答える