Pasar DTO a mi constructor ViewModels para mapear propiedades

architecture asp.net-mvc c# dapper

Pregunta

En mi solución tengo dos proyectos.

Proyecto 1 (Core) Asignar SQL a DTO usando Dapper

Proyecto 2 (WebUI - ASP.NET MVC 4) Aquí uso un ViewModel por vista.

Ejemplos de un controlador

  [HttpGet]
    public ActionResult Edit(int id)
    {
        // Get my ProductDto in Core
        var product = Using<ProductService>().Single(id);
        var vm = new ProductFormModel(product);

        return View(vm);
    }

Ejemplos de un ViewModel

public class ProductFormModel : BaseViewModel, ICreateProductCommand
    {
        public int ProductId { get; set; }
        public int ProductGroupId { get; set; }
        public string ArtNo { get; set; }
        public bool IsDefault { get; set; }
        public string Description { get; set; }
        public string Specification { get; set; }
        public string Unit { get; set; }
        public string Account { get; set; }
        public decimal NetPrice { get; set; }

        public ProductFormModel(int productGroupId)
        {
            this.ProductGroupId = productGroupId;
        }

        public ProductFormModel(ProductDto dto)
        {
            this.ProductId = dto.ProductId;
            this.ProductGroupId = dto.ProductGroupId;
            this.ArtNo = dto.ArtNo;
            this.IsDefault = dto.IsDefault;
            this.Description = dto.Description;
            this.Specification = dto.Specification;
            this.Unit = dto.Unit;
            this.Account = dto.Account;
            this.NetPrice = dto.NetPrice;
        }

        public ProductFormModel()
        {
        }
    }

Explicación: Obtendré mis DTO en mi controlador usando una clase de servicio en el proyecto (Core). Luego creo mi ViewModel y paso el DTO al constructor en ViewModel. También puedo usar esta vista para agregar un nuevo producto porque mi ViewModel puede tomar un constructor vacío.

¿Alguien tiene experiencia de esto? Me pregunto si estoy de esta manera tendrá problemas en el futuro a medida que el proyecto se agrande.

Sé que esto no tiene nada que ver con Dapper. Pero aún me gustaría una buena manera de explicar mi solución.

Respuesta aceptada

Creo que estarás bien usando tu enfoque actual. Más importante aún, comience de esta manera y refactorice si comienza a encontrar problemas relacionados con su código de mapeo de objetos (en lugar de pensar demasiado en ello de antemano).

Otra forma de organizar la lógica de mapeo que uso a veces es emplear métodos de extensión. De esta forma, el código de mapeo se mantiene separado del modelo de vista en sí mismo. Algo como:

public static class ProductMappingExtensions
{
    public static ProductFormModel ToViewModel(this ProductDto dto)
    {
        // Mapping code goes here
    }
}

// Usage:

var viewModel = dto.ToViewModel();

Sin embargo, otro enfoque sería utilizar un marco de mapeo como AutoMapper : este es un buen ajuste en particular si su lógica de mapeo es simple (muchas asignaciones 1: 1 entre propiedades).

Pero, de nuevo, comience de manera simple y refactorícese cuando lo necesite .


Respuesta popular

Me doy cuenta de que esta es una respuesta un poco tarde, pero tal vez ayudará a alguien en el futuro.

Esta forma de hacer un mapeo entre objetos rompe la "S" de los principios SÓLIDOS, porque la responsabilidad de ViewModel es preparar los datos en sus propiedades para estar listos para ser utilizados por la vista y nada más, por lo tanto, los objetos de mapeo no deberían estar encendidos. son responsabilidades

Otro inconveniente de esta manera es que también rompe el principio de OO 'Loose Coupling' ya que ViewModel está fuertemente acoplado con su DTO.

Creo que, incluso cuando estamos en el primer paso del proyecto, hay algunos principios OO importantes que nunca deberíamos romper, así que usar clases de mapeo, ya sea automático (AutoMapper, ValueInjecter ...) o manual, es definitivamente mejor.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué