Cómo cambiar el modelo de edición/postmodelo al modelo de dominio

Question

En un proyecto ASP.NET MVC, estamos utilizando AutoMapper para mapear desde el modelo de dominio al modelo de vista y, a veces, también aplanamos una jerarquía mientras lo hacemos. Esto funciona como un amuleto y hace que la lógica de renderizado de nuestros puntos de vista sea muy simple.

La confusión comienza cuando queremos ir al revés de viewmodel (o postmodelo o editmodel) al modelo de dominio, especialmente al actualizar los objetos. No podemos usar automatizado/mapeo bidireccional porque:

1. tendríamos que unflat la jerarquía aplanada
2. todas las propiedades en el modelo de dominio tendría que ser mutable/tienen los emisores públicos
3. los cambios Desde la vista, no siempre son solo las propiedades planas que se vuelven a asignar al dominio, sino que a veces se deben llamar a métodos como "ChangeManagerForEmployee()" o similar.

Esto también se describe en el artículo Bogards Jimmy: The case for two-way mapping in AutoMapper, pero la solución a esto no se describe en detalle, sólo que van:

De EditModel a CommandMessages - que va desde el loosely- tipeado EditModel a mensajes fuertemente tipados y descompuestos. Un único EditModel podría generar media docena de mensajes.

En un similares SO question hay una respuesta por Mark Seeman donde se menciona que

Utilizamos creadores de mapas y servicios abstractos para asignar una PostModel a un objeto de dominio

pero los detalles - la implementación conceptual y técnica, queda fuera.

Nuestra idea en este momento es:

1. Recibir FormCollection en el método de la acción del controlador
2. Obtener el modelo de dominio original y aplanarlo a viewModelOriginal y viewModelUpdated
3. La fusión de la FormCollection en viewModelUpdated usando UpdateModel()
4. Usa algún método de ayuda genérico para comparar viewModelOriginal con viewModelUpdated
5. Cualquiera A) Generar CommandMessages un Jimmy Bogard o B la) mutar las diferencias directamente en el modelo de dominio a través de propiedades y métodos (tal vez que trazan los 1-1 propiedades directamente a través de AutoMapper)

Puede alguien proporcionar algunos ejemplos de cómo vienen de FormCollection través editmodel/postmodel a modelo de dominio? "CommandMessages" o "mapeadores y servicios abstractos"?

Answer 1

uso el siguiente patrón:

[HttpPost] 
public ActionResult Update(UpdateProductViewModel viewModel) 
{ 
    // fetch the domain model that we want to update 
    Product product = repository.Get(viewModel.Id); 

    // Use AutoMapper to update only the properties of this domain model 
    // that are also part of the view model and leave the other properties unchanged 
    AutoMapper.Map<UpdateProductViewModel, Product>(viewModel, product); 

    // Pass the domain model with updated properties to the DAL 
    repository.Update(product); 

    return RedirectToAction("Success"); 
} 

Answer 2

Es posible que desee considerar CQRS (Segregación Responsabilidad comando de consulta - Creo que esto podría ser el concepto que faltaban), posiblemente incluso con evento de abastecimiento.

Es básicamente una práctica de separar la lógica de lectura de una fuente de datos y escribir en una fuente de datos, incluso puede significar tener diferentes modelos de datos para leer y escribir.

Este podría ser un buen lugar para empezar: http://abdullin.com/cqrs/

Answer 3

Opción C: Ponga todo en la acción del controlador. Luego, si eso se pone peludo, descompóngase en servicios (mapeadores abstractos) o en mensajes-como-métodos (el modo de mensaje de comando).

mensaje

Comando manera:

public ActionResult Save(FooSaveModel model) { 
    MessageBroker.Process(model); 

    return RedirectToAction("List"); 
} 

y el procesador:

public class FooSaveModelProcessor : IMessageHandler<FooSaveModel> { 

    public void Process(FooSaveModel message) { 
     // Message handling logic here 
    } 

} 

Esto es realmente sólo acerca de cómo mover el "proceso" de la forma de la acción del controlador y en los controladores individuales, especializados .

Pero, realmente solo iría por esta ruta si las acciones del controlador se ponen peludas. De lo contrario, solo tome el formulario y realice las actualizaciones apropiadas contra los modelos de dominio según sea necesario.

Answer 4

Aquí hay algunas similitudes con lo que he estado haciendo. Mi jerarquía de modelos de vista es solo un tanto aplanada de sus equivalentes de objeto de dominio, pero tengo que lidiar con llamar métodos de servicio explícitos en guardar para hacer cosas como agregar colecciones secundarias, cambiar valores importantes, etc., en lugar de simplemente mapear de forma inversa. También tengo que comparar fotos anteriores y posteriores.

Mi salvación es Ajax publicada como JSON en una acción de MVC y entra en esa acción mágicamente ligada a una estructura de modelo de vista por MVC. Luego uso AutoMapper para transformar el modelo de vista de nivel superior y sus descendientes a su estructura de dominio equivalente. He definido una cantidad de ITypeConverters AutoMapper personalizados para aquellos casos en los que se ha agregado un nuevo elemento secundario en el cliente (estoy usando Knockout.js) y necesito llamar a un método de servicio explícito. Algo así como:

  foreach (ChildViewModel childVM in viewModel.Children) 
     { 
      ChildDomainObject childDO = domainObject.Children.Where(cdo => cdo.ID.Equals(childVM.ID))).SingleOrDefault(); 
      if (childDO != null) 
      { 
       Mapper.Map<ChildViewModel, ChildDomainObject>(childVM, childDO); 
      } 
      else 
      { 
       MyService.CreateChildDO(someData, domainObject); // Supplying parent 
      } 
     } 

hago una cosa similar para eliminaciones y este proceso cascadas bastante bien hacia abajo a través de toda la estructura. Supongo que una estructura aplanada podría ser más fácil de trabajar o más difícil. Tengo un AbstractDomainViewModel con una ID con la que hago la coincidencia anterior, lo que ayuda.

Necesito hacer comparaciones antes y después de la actualización porque mi capa de servicio llama a la validación del desencadenante que puede afectar a otras partes del gráfico del objeto, y esto dicta lo que JSON necesito devolver como respuesta Ajax. Solo me importan los cambios que son relevantes para la UI, entonces transformo el objeto de dominio guardado de nuevo en un nuevo modelo de vista y luego tengo un método de ayuda para comparar los 2 modelos de vista, usando una combinación de comprobaciones manuales iniciales y reflexión.