MVC3 - Viewmodels y funcionalidad del controlador: patrones de diseño sugeridos

Question

He creado un sitio de entrada de boletos simple basado en MVC3 para una aplicación de centro de llamadas menos utilizado y estoy intentando refactorizar mi prototipo para adherirme mejor a los patrones de diseño en parte para que sea más mantenible en el futuro, pero principalmente como un ejercicio de aprendizaje. La vista orientada al usuario es un formulario que consiste en información básica del usuario, además de unos pocos paneles que permiten la selección de varios tipos de recursos. Cada tipo de recurso (hardware, software, etc.) se muestra de la misma manera: el uso de cuadros de lista duales y filtrables con botones agregar/eliminar, un textea de "justificación" opcional que se muestra condicionalmente si un recurso solicitado requiere justificación y comentarios generales. He construido el siguiente model de vista para los paneles individuales:

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

El Modelo de vista principal se compone de múltiples requisitos según sea necesario:

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

He creado una vista fuertemente escrita para SimpleRequestViewModel (y su variante) y una edición de edición fuertemente escrita para requestableList que algue los cuadros de listas duales, el filtrado y la jQuery. Todos se vuelven bien y funcionan, pero el código huele actualmente.

Al publicar en el controlador, si el modelo es válido, debo traducirlo en una descripción de texto legible para crear un nuevo ticket en la aplicación Call Center. No se siente correcto que el controlador realice esa traducción en texto legible, pero me encuentro con obstáculos cuando trato de diseñar otra clase para traducir los modelos ViewModels.

1. Solo se publican los valores del elemento seleccionados, por lo que antes de traducir la solicitud en texto primero debo buscar el texto apropiado para los valores proporcionados (se requieren en la descripción). El controlador es actualmente el único objeto que tiene acceso al modelo de datos del centro de llamadas para esta consulta de búsqueda.
2. Hay 2 modelos de visión similares que contienen combinaciones variables de requisitos, por lo que cualquier traductor debe poder traducir las diversas combinaciones. Uno solo tiene hardware y software, otro puede tener software de hardware y algunos más requisitos.

Consideré anular toString () directamente en el modelado de vista, pero no me gustó esa lógica comercial (representación condicional) allí, y una vez que se publique, el modelado ViewModel no contiene el texto para los elementos seleccionados en el cuadro de lista, por lo que necesitaría acceso al modelo de datos. La traducción de los valores publicados al texto, ya que actualmente se maneja en el controlador huele a medida que se maneja en una declaración Switch. El controlador toma cada lista de requestal de publicaciones y complementa los campos originales "disponibles" antes de que construya la nueva descripción del ticket.

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

Entonces, mi (s) pregunta (s):

1. ¿Qué patrones son técnicas recomendaría para realizar la traducción de la descripción de ViewModel de ViewModel publicado?
2. ¿Cómo se maneja normalmente el problema de "solo valor de publicaciones" con los cuadros de selección cuando necesita el texto y el valor?
3. ¿Hay una mejor manera de abordar este problema?

Nuevamente, espero que esta sea una experiencia de aprendizaje para mí y estoy más que dispuesto a proporcionar información o descripción adicional si es necesario.