MVC3 - ビューモデルとコントローラー機能：推奨される設計パターン

Question

私は、使用不能ではないコールセンターアプリケーション用のシンプルなMVC3ベースのチケットエントリサイトを構築しました。プロトタイプをリファクタリングして、デザインパターンをよりよく遵守して、今後はよりメンテナンスしやすくしますが、ほとんどが学習演習です。ユーザー向けビューは、さまざまなリソースタイプを選択できるいくつかのパネルに加えて、基本的なユーザー情報で構成されるフォームです。各リソースタイプ（ハードウェア、ソフトウェアなど）は、同じ方法で表示されます。追加/削除ボタンを備えたデュアルでフィルター可能なリストボックスを使用して、要求されたリソースに正当化を必要とする場合に条件付きで表示されるオプションの「正当化」テキストアレア、および一般的なコメントです。個々のパネル用の次のViewModelを作成しました。

public class RequestableList
{
    // list of requestable items ids requiring justification
    private List<string> _restrictedItems = new List<string>();
    public List<string> RestrictedItems
    {
        get { return _restrictedItems; }
        set { _restrictedItems = value; }
    }

    // the key-value pairs from which to populate available items list
    private Dictionary<string, string> _availableItems = new Dictionary<string, string>();
    public Dictionary<string, string> AvailableItems
    {
        get { return _availableItems; }
        set { _availableItems = value; }
    }

    // item ids requested by user
    private List<string> _requestedItems = new List<string>();
    public List<string> RequestedItems
    {
        get { return _requestedItems; }
        set { _requestedItems = value; }
    }
}

メインビューモデルは、必要に応じて複数のリクエストアブレリストで構成されます。

public class SimpleRequestViewModel
{
    public UserInfo userInfo { get; set; }
    public RequestableList Software {get;set;}
    public RequestableList Hardware {get;set;}
    public RequestableList Access {get;set;}
    public string SoftwareAdditionalInfo { get; set; }
    public string HardwareAdditionalInfo { get; set; }
    public string AccessFileMailShare { get; set; }
    public string AccessAdditionalInfo { get; set; }
    public string SoftwareJustification { get; set; }
    public string HardwareJustification { get; set; }
    public string AccessJustification { get; set; }
    public string Comment { get; set; }
}

SimplereQuestViewModel（およびそのバリアント）の強力なタイプ化されたビューと、デュアルリストボックス、フィルタリング、およびjQueryをワイヤー化するRequestAblElistの強力なタイプされたEditortemplateを作成しました。すべてがうまくレンダリングされ、機能していますが、コードは現在臭いがします。

コントローラーに投稿するとき、モデルが有効な場合は、コールセンターアプリに新しいチケットを作成するために、読み取り可能なテキスト説明に変換する必要があります。コントローラーがその翻訳を読み取り可能なテキストに実行することは正しいとは感じませんが、ViewModelを翻訳するために別のクラスを設計しようとするときにハードルに遭遇します。

1. 選択したアイテム値のみが投稿されるため、リクエストをテキストに変換する前に、最初に提供された値に適切なテキストを検索する必要があります（説明で必要です）。現在、コントローラーは、このルックアップクエリのコールセンターデータモデルにアクセスできる唯一のオブジェクトです。
2. RequestAbleListsのさまざまな組み合わせを含む2つの同様のビューモデルがあり、翻訳者はさまざまな組み合わせを翻訳できる必要があります。 1つはハードウェアとソフトウェアのみ、もう1つはハードウェアソフトウェアを持ち、さらにいくつかのRequestAbleListsがあります。

私はviewmodelで直接tostring（）をオーバーライドすることを検討しましたが、そこでそのビジネスロジック（条件付きレンダリング）が好きではありませんでしたが、繰り返しますが、viewmodelにはリストボックスの選択したアイテムのテキストが含まれていないため、アクセスが必要になります。データモデルへ。現在、コントローラーで処理されているテキストへの投稿値の翻訳は、スイッチステートメントで処理されているときに臭いがします。コントローラーは、投稿された各リクエストアブルリストを取得し、新しいチケットの説明を作成する前に元の「利用可能な」フィールドに入力します。

switch (requestCategory)
{
    case RequestableCategory.Software:
        itemList = sde.GetSoftware();
        break;
    case RequestableCategory.Hardware:
        itemList = sde.GetHardware();
        break;
    case RequestableCategory.Access:
        itemList = sde.GetAccess();
        break;
    case RequestableCategory.Telecom:
        itemList = sde.GetTelecom();
        break;
    default:
        throw new ArgumentException();
}

だから、私の質問：

1. 投稿されたViewModelをチケット説明翻訳に実行するために、どのようなパターンをお勧めしますか？
2. 通常、テキストと値だけでなくテキストが必要なときに、選択ボックスで「値のみの価値のみ」の問題をどのように処理しますか？
3. 私がこの問題に近づくためのより良い方法はありますか？

繰り返しますが、これが私にとって学習体験であり、必要に応じて追加情報や説明を提供する意思があることを願っています。