Should a model itself do some calculation?

Question

Hi, I have been learning ASP.NET MVC for few months. I have learned about view, controllers and models and stuff. To design a view we always need a model, Usually a model is a just a class which we fill with data and pass to a view. I have a question here should model itself do some calculation or it should be just dumb.

For example I have a site where I load books by Users. 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 doesn't do anything, just a template. Now if I modify the code and write 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();
  }
}

In here books are collected depending on what user has been selected. Now its much easier to work with.

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

Help from the experts will be greatly appreciated.

Regards Parminder

Answer 1

In general, this kind of work should be done in the model. This is for a couple of reasons. First, if getting the user books requires a database connection, you don't want to be doing that from the view - it will just slow it down. The other thing to remember is that there could be multiple views, and you would need to duplicate that code in all of the views (web clients, maybe rich clients, etc).

In the MVC pattern, the views should be the "dumb" pieces. This allows easier use of multiple views and changing views when needed. It's also easier to test code when it doesn't require a view, so you could test the model without bringing up a web client.

Jeff

Answer 2

You want to separate all of your business logic, and data validation into the model. Usually that includes "grouping" datasets and such or filtering data by some criteria.

You want to separate all calls to these methods of the model in the controller, who's responsibility is to retrieve and send data to and from the model. The controller then passes the applicable data set into the view.

The Helpers are logic that is used by the view to do presentation logic (not business logic or validation) such as printing menus and such.

The View is where you will use the Helpers (or not, they are not required to use MVC properly but they do "help" :p) to write HTML, CSS and JS to the browser. You may also separate commonly used view modules into partial views that you can include on more then one view.

You can further seperate things into a ViewModel, but then you are going outside of "strict" MVC. In this case, you would use the ViewModel to help the view interact with the model - basically the ViewModel is a modular controller. In this case, the controller would do much less then what little it does already.

However, this is generally overkill for web applications. Because web apps have a single flow of execution (the request) separating things into a ViewModel becomes unnecessary. However, in GUI code, the ViewModel becomes much more useful (as GUIs have much more then a single flow of execution).

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

Hope this helps :)

Answer 3

it is the view that is "dumb". all it does is display the manipulated data.

the controller simply fetches data from the model for the view... again the controller is ONLY a go between.

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

Answer 4

You can do it a couple of ways, but I'd say the easiest way would be to pass in the reference identifier for the user which you are trying to access through to the controller action (as below) and let it do all the data access calls.

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

Then in this controller action you can look up the user details and the books for this user, set the properties on the view model instance and return it to the view to access.

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

This way the view remains dumb (which it should be) and the model is relatively simple. This also helps with testing purposes.

Hope this helps.

Answer 5

MVC is a pattern by itself. I really don't have any experience with ASP.NET MVC, but worked several times and used MVC pattern. Sometimes, MVC is realted to other development patterns like heartbeat, memento, state ...

Answer 6

When you have a viewmodel that is different from your domain model, you shouldn't map the domain model to the viewmodel inside the viewmodel. It would make the viewmodel class responsible for more than one thing. You can do the mapping in the controller or in a service layer.

Answer 7

thanks a lot everyone. I appritiate your help.

Regards Parminder

Answer 8

Check out this. You are talking about VIEW model, not domain model. There is a huge difference. View model should be dumb, it's just a placeholder for data which allows your views to be more strongly typed. Domain model must be a heart of your app, it must contain ALL business logic.