MVC3 - ViewModels e Funzionalità del controller: modelli di progettazione suggeriti

Question

Ho creato un semplice sito di ingresso del biglietto basato su MVC3 per una domanda di call center tutt'altro che utilizzabile e sto tentando di rifactare il mio prototipo per aderire meglio ai modelli di progettazione in parte per renderlo più mantenebile in futuro, ma soprattutto come esercizio di apprendimento. La vista rivolta all'utente è un modulo costituito da informazioni sull'utente di base oltre a alcuni pannelli che consentono la selezione di vari tipi di risorse. Ogni tipo di risorsa (hardware, software, ecc.) Viene visualizzato allo stesso modo: utilizzando caselle di elenchi a doppio e filtrabile con pulsanti ADD/REMOVE, una textErato "giustificazione" opzionale che viene visualizzata in modo condizionale se una risorsa richiesta richiede giustificazione e commenti generali. Ho costruito i seguenti ViewModel per i singoli pannelli:

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; }
    }
}

Il punto di vista principale è quindi composto da più richieste ablelistiche, se necessario:

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; }
}

Ho creato una vista fortemente tipizzata per SimpleRequestViewModel (e la sua variante) e un editTemPlate fortemente digitato per RequestAbleList che fila le doppie boxe, filtraggio e jQuery. Tutto rende bene e funziona ma il codice attualmente ha un odore.

Durante la pubblicazione sul controller, se il modello è valido, devo tradurlo in una descrizione del testo leggibile per creare un nuovo ticket nell'app Call Center. Non è giusto che il controller esegui quella traduzione in testo leggibile, ma mi imbatto in ostacoli quando provo a progettare un'altra classe per tradurre i ViewModels.

1. Vengono pubblicati solo i valori degli elementi selezionati, quindi prima di tradurre la richiesta in testo devo prima cercare il testo appropriato per i valori forniti (sono richiesti nella descrizione). Il controller è attualmente l'unico oggetto che ha accesso al modello di dati del call center per questa query di ricerca.
2. Esistono 2 modelli di vista simili contenenti combinazioni variabili di richieste Ablelistiche, quindi qualsiasi traduttore deve essere in grado di tradurre le varie combinazioni. Uno ha solo hardware e software, un altro può avere un software hardware e qualche altra richiesta.

Ho preso in considerazione la prevalente toString () direttamente nel ViewModel ma non mi piaceva quella logica aziendale (rendering condizionale) lì e, una volta pubblicato, una volta pubblicato, ViewModel non contiene il testo per gli elementi selezionati nella casella di elenco al modello di dati. La traduzione dei valori pubblicati in testo in quanto è attualmente gestito nel controller odori mentre viene gestito in un'istruzione switch. Il controller prende ogni richiesta pubblicata e popola i campi "disponibili" originali prima di costruire la nuova descrizione del biglietto.

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();
}

Quindi, le mie domande:

1. Quali schemi sono le tecniche consiglieresti di eseguire la traduzione di Descrizione del biglietto?
2. Come si gestisce in genere il problema "solo valore post" con caselle selezionate quando hai bisogno del testo e del valore?
3. C'è un modo migliore per io per affrontare questo problema?

Ancora una volta, spero che questa sia un'esperienza di apprendimento per me e sono più che disposto a fornire ulteriori informazioni o descrizioni se necessario.