Share via

ASP.NET MVC - Should we have methods in view model classes?

Question

Sunday, April 1, 2012 2:44 AM

I was debating with a colleague of mine against having methods in view model classes. 

Here is the questions:

Should view model classes access business objects directly to populate properties required for view. 

Or, should we create a separate mapper/assembler class for this?

At least in my knowledge, as per the design principles, ideally we should not have methods in view model classes and create a separate class to manage interaction between business objects and view models. 

Your thoughts....??

All replies (5)

Sunday, April 1, 2012 3:04 AM ✅Answered

ViewModel classes should not be responsible for populating themselves. Full stop. 

However, taking your question literally, yes - there are times when a ViewModel class can have methods in it in my opinion. For example, the following is a ViewModel from my site. Note the Checked method:

    public class ArticleRating
    {
        public int ArticleID { get; set; }
        public string Title { get; set; }
        public int Rating { get; set; }
        public int TotalRaters { get; set; }
        public double AverageRating { get; set; }
        public IHtmlString Checked(double lower, double upper) {
            return this.AverageRating > lower && this.AverageRating <= upper ? new HtmlString(" checked=\"checked\"") : null;
        }
    }

That method is purely related to presentation and is used in the View to determine which rating star should be displayed. It replaces the Utils method mentioned in this article: http://www.mikesdotnetting.com/Article/114/jQuery-Star-Rating-with-ASP.NET-MVC

Sunday, April 1, 2012 4:48 AM ✅Answered

Am I wrong anywhere in defending for not having methods in VM classes?

I beleive yYou are not wrong, business logic /data access related methods should not be placed in the ViewModel classes.The fiunction mentioned by Mike above is a presentation only function (for the view only) and this is an exceptional case.

Regarding the proc/cons from using the ViewModels, here is what I have in mind right now.

Proc:

  1. You will be able to send only the information that is required for the View.For example, say that you want to dispaly the customer's information in the view.Instead of sending the whole Customer data (including the confedential data like credit card, passwords...etc) , you can only include the information that you want dispaly in the view.This way, if the one who created the view is someone other than you, you will make sure that he/she will not going to dispaly these confidential information by mistake.
  2. Your views will not have direct depency with the business entity.This means that any change to the business entities will be done in outside the View itself(e.g. in the assembler or in the data access).

Also, you can find more advantages in Rachel's article here.

Cons:

  1. You will have  to manage more classes.
  2. You will need to write the mapping yourself or using one of the open source class mappers.

Hope it helps.

Sunday, April 1, 2012 3:44 AM

Hello Mike, thanks for your reply. I completely agree with you. 

Could you please share some pro/cons of not-having/haivng methods in view model classes?

In my opinion, one of the reason for not having methods is Single Responsibility Principle.

For example:

I have an  AccountInfoVM for Account Info view. Now suppose you need to support additional types of account (savings, fixed deposit). In this case, you'll have different logic for calculating interest for each of the account type. If you have methods in your VM class for interest calcualtion or calling different business classes for this, you have 3 reasons for modifying your VM class. Whereas, if you have created separate Assembler classes for each of the account type, you don't need to change your VM and still re-use this VM for all the 3 views.

Am I wrong anywhere in defending for not having methods in VM classes?

Those who support having methods in VM, please share your thoughs.

Thanks in advance for your valuable time!

Sunday, April 1, 2012 2:26 PM

If you have methods in your VM class for interest calcualtion or calling different business classes for this, you have 3 reasons for modifying your VM class.

The correct place for that type of calculation is in your concrete account classes, all of which will either implement IAccount which specifies that classes must implement a method called CalculateInterest(), or they will inherit from a base class that has a virtual CalculateInterest() method. Your ViewModel will include an IAccount property or a BaseAccount property (depending on your previous approach) and it will be the controller's responsibility to populate that property with the correct type.

At no point will the ViewModel take part in the decision making process. It is just a convenience container for data for a specific View. It's primary purpose is to provide you with intellisense at design time.

Thursday, April 5, 2012 8:42 AM

Protect the business logic to flow into the UI. Add a service layer between the controller and the repository, and use the view model as a DTO between the UI and the service layer.

  • Last updated on