MVC, is a domain M-model or is it limited and prepared data?

Question

I am working on an MVC web application. I'm just wondering, is it M, a domain model or poco classes, or is it refined and processed data, ready to be sent to View for display?

For example, consider a database table:

Id, Name, Salary 

To display I need 4 columns instead of 3:

 Id, Name, Salary, Annual Salary (Salary * 12) 

I am confused according to the template directive, what will happen in my Model class, will I do AnnualSalary=Salary*12 in the controller and pass all 4 pieces of data for viewing, or will my model return 4 columns?

Another point is that if I need to add an address from another table with these four columns, do I need to return the models and specify the required data or in the controller, I have to query two different data tables and then select and transfer the data to the View?

Answer 1

A good practice in ASP.NET MVC can be to separate the model from the database and the model for presentation. In your case, we will have two models: EmployeeDTO and Employee.

 public class EmployeeDTO { public int Id { get; set; } public string Name { get; set; } public int Salary { get; set; } } public class Employee { public int Id { get; set; } public string Name { get; set; } public int Salary { get; set; } public int AnnualSalary { get { return this.Salary * 12; } } } 

After that, on your controller, you map EmployeeDTO to Employee (to read the action) and Employee to EmployeeDTO (to create / update actions). For example, the Read method:

 public ActionResult Read(int id) { EmployeeDTO employeeDTO = db.Employee.Find(id); Employee employee = new Employee() { Id = employeeDTO.Id, Name = employeeDTO.Name, Salary = employeeDTO.Salary }; return View(employee); } 

With this convention, you can implement DataAnnotations for EmployeeDTO, which does not automatically apply to Employee (like your view) and vice versa. In your case, you can add a new property that does not affect the database schema.

Hope this helps.

Answer 2

Based on the MVC pattern, the controller is responsible for providing all the information that View must do. In addition, ViewModel is a class that can be a combination of all the information for viewing from different sources.

Therefore, it is recommended that your Annual Salary calculated in your controller, placed in the ViewModel, and the ViewModel sent to the view.

This is a very effective and popular method among developers.

When you have dozens of different meanings for moving to a view, the same flexibility that allows you to quickly add a new entry or rename an existing one will become your worst enemy. You remain on your own to track the names and values ​​of elements; you do not get help from Microsoft IntelliSense and compilers. The only proven way to deal with software complexity is by design. Thus, defining an object model for each view helps you keep track of what such a view is really necessary. I suggest you define a view-model class for each view that you add to the application .

- "Microsoft ASP.NET MVC Programming" by Dino Esposito

Update:

My guess is that Annual Salary is a ViewModel property, not a business property.

Answer 3

Regardless of how you communicate with the submission, annual payroll is the domain logic and therefore should be part of your domain model.

Preventing a domain leak into your controller seems risky to me.

Answer 4

I'm just wondering, is it M, a domain model or poco classes, or is it refined and processed data, ready to be sent to View for display?

The MVC pattern is definitely defined and there is no 1-1 mapping between M, V, C and classes.

A model is all that is used to obtain the information necessary for presentation. Therefore, this is your repository / wcf client / dto / entity, etc.

The sample does not really care about how you get the information, what it consists of or how the information is structured. He simply says that the Controller should receive information from the Model and transfer it to the View.

Now ASP.NET MVC uses ViewModels, which are designed to be used as adapters for model information and, therefore, adapt them so that the view does not contain logic for transforming information.

VM itself can use your entities, your repositories, etc. But usually the best approach is to just use your objects (to make the controllers cleaner).