Should the model itself perform some calculations?

Question

I have been studying ASP.NET MVC for several months. I found out about looks and controllers, models, etc. To design a presentation, we always need a model. Typically, a model is simply a class that we populate with data and move on to the view. I have a question here: should the model itself do some calculations, or should it be dumb?

For example, I have a site where I upload Book to User s. My model class is as follows:

 public class FormViewModel { public User MyUser {get; set;} public Books UserBooks {get; set;} //Constructor here. public FormViewModel(User _user, Books _userBooks) { this.MyUser=_user; this.UserBooks=_userBooks; } } 

This class does nothing - it's just a template. Now, if I change the code as follows:

 public class FormViewModel { public User MyUser {get; set;} public Books UserBooks {get; set;} //Constructor here. public FormViewModel(User _user) { this.MyUser=_user; this.UserBooks=_user.GetBooks(); } } 

which Book going to depend on which User was selected. Now it is much easier to work with him.

I just want to know what a good approach is according to the MVC patterns and methods.

Answer 1

You can do this in several ways, but I would say that the easiest way would be to pass the link identifier for the user you are trying to access to the controller action (as shown below), and let this make all data access calls.

 public void GetUserAndDetails(Guid userId) { ... } 

Then, in this controller action, you can view the user and book data for this user, set the properties of the view model instance and return it to the view access to which.

 FormViewModel model = new FormViewModel(); model.MyUser = GetUser(userId); model.UserBooks = GetUserBooks(userId); return View(model); 

Thus, the view remains dumb (which should be), and the model is relatively simple. It also helps for testing purposes.

Hope this helps.

Answer 2

You want to separate all your business logic and data validation in a model. This usually involves “grouping” the data sets and such or filtering the data according to some criteria.

You want to separate all the calls to these model methods in the controller, who is responsible for extracting and sending data to and from the model. The controller then passes the appropriate data type to the view.

Helpers are the logic that a view uses to represent presentation logic (not business logic or validation), such as the print menu, etc.

In the view, you will use Helpers (or not, they are not required to use MVC correctly, but they "help": p) to write HTML, CSS and JS in the browser. You can also separate commonly used viewers with partial views, which you can include in more than one view.

You can further split things up into a ViewModel, but then you go beyond the "strict" MVC. In this case, you should use the ViewModel to help interact with the model - basically, the ViewModel is a modular controller. In this case, the controller will do much less than little.

However, this is usually too large for web applications. Since web applications have one thread of execution (request) sharing things in the ViewModel, it becomes unnecessary. However, in the GUI code, ViewModel becomes much more useful (since graphical interfaces have much more than one thread of execution).

You always want to divide the business logic into a model, a period. Remember that you should not associate a controller with your model - so that you can use your model elsewhere on other controllers or even expose it as a web service.

Hope this helps :)

Answer 3

In general, such work should be done in the model. There are several reasons for this. Firstly, if you need a database connection to get custom books, you don’t want to do this from a view - it will just slow down. Another thing to keep in mind is that there can be several kinds, and you will need to duplicate this code in all views (web clients, possibly rich clients, etc.).

In an MVC template, the views must be "dumb". This makes it easier to use multiple views and change views if necessary. It is also easier to test the code when it does not require viewing, so you can test the model without involving a web client.

Jeff

Answer 4

this is an opinion that is "stupid." everything he does is display managed data.

the controller simply extracts data from the model for presentation ... again, the controller is ONLY in between.

the model does everything. it stores data and contains classes and methods that manipulate it.

Answer 5

If you have a viewmodel that is different from your domain model, you should not map the domain model to the view model inside the viewmodel. This will make the viewmodel class more than one. You can perform the mapping in the controller or at the service level.

Answer 6

Mark it . You are talking about a VIEW model, not a domain model. This is a huge difference. The view model should be dumb, it is just a placeholder for data, which allows you to more accurately type your views. The domain model should be the heart of your application, it should contain the business logic of EVERYTHING .

Answer 7

MVC is a template in itself. I really have no experience with ASP.NET MVC, but have worked several times and used the MVC pattern. Sometimes MVC is driven by other developmental patterns, such as heartbeat, memory, condition ...

Answer 8

No business logic allowed for model! This is a bad design! Your logic should be in controllers and more precisely: put your logic in helpers (helpers can consume your BLL and / or DAL), and then use your helpers in your controllers.