Passing DTO to the ViewModels constructor to display properties

Question

In my solution, I have two projects.

Project 1 (Core) Mapping SQL to DTO Using Dapper

Project 2 (WebUI - ASP.NET MVC 4) Here I use ViewModel for each view.

Controller Examples

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

ViewModel Examples

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

Explanation: I will get my DTOs in the controller using the service class in the project (Core). Then I create my ViewModel and pass the DTO to the constructor in the ViewModel. I can also use this view to add a new product, because my ViewModel can accept an empty constructor.

Does anyone have any experience with this. I wonder if in this way I will have problems in the future when the project becomes larger?

I know this has nothing to do with Dapper. But I still would like to find a good way to explain my decision.

Answer 1

I think you will make good use of your current approach. More importantly, start with this and refactor if you start to run into problems with your object's matching code (instead of thinking too much about it in advance).

Another way to organize the cartographic logic that I sometimes use is to use extension methods. Thus, the display code is stored separately from the presentation model itself. Sort of:

 public static class ProductMappingExtensions { public static ProductFormModel ToViewModel(this ProductDto dto) { // Mapping code goes here } } // Usage: var viewModel = dto.ToViewModel(); 

Another approach is to use a display structure such as AutoMapper - this works well, especially if your display logic is simple (lots of 1: 1 mappings between properties).

But then again, run simple and refactoring when you need to .

Answer 2

I understand this is a bit late answer, but maybe this will help someone in the future.

This method of performing comparisons between objects violates the "S" of SOLID principles, since the responsibility of the ViewModel is to prepare the data in its properties so that it is ready to be used in the view, and nothing more, so the matching objects should not perform its duties .

Another disadvantage of this method is that it also violates the OO "Loose Coupling" principle, as you ViewModel are closely related to your DTO.

I think that even when we are at the first stage of the project, there are some principles of OO importers that we should never break, so using matching classes, whether auto (AutoMapper, ValueInjecter ...) or manually, is definitely better.