ViewModel Structure Decision

Question

As my domain classes I have Person and FavoritePerson classes as follows.

public class CompanyPerson : ICompanyPerson
{
    [Key]
    public Guid PersonId { get; set; }      
    public string Title { get; set; }
    public string Description { get; set; }
}

public class CompanyFavoritePerson : IFavoritePerson
{
    [Key]
    public Guid FavoritePersonId { get; set; }

    [Column(TypeName = "datetime2")]
    public DateTime CreateDate { get; set; }

    public Guid? CompanyPerson_PersonId { get; set; }

    [StringLength(128)]
    public string CompanyUser_UserId { get; set; }

    public virtual CompanyPerson CompanyPerson { get; set; }

    public virtual CompanyUser CompanyUser { get; set; }
}

In my web application I will need to show List of Favorite Person. So my view model is like this;

public class FavoritePersonViewModel 
{
    public Guid FavoritePersonId { get; set; }
    public DateTime CreateDate { get; set; }
    public Guid? CompanyPerson_PersonId { get; set; }
    public string CompanyUser_UserId { get; set; }
    //Option1: PersonViewModel PersonViewModel {get; set; }
    //Option2: public string Title {get;set;}
}

Since I need to show Title of the favorite user in the list (where title belongs to Person class) which way will match with best practices?

Referencing a viewModel from another viewModel or extend viewModel with required extra attributes and fill them in business layer?

I'd personally go with option 2, but it's really pretty subjective, and depends on other architecture — Jedediah, Aug 09 '15 at 02:37
Either will work, so this question is too opinion based. If the only property of `PersonViewModel` that you need in the view is `Title`, then I would personally use option 2 — , Aug 09 '15 at 02:39
I know this is very opinion based question. However, Idea of referencing a ModelView from another ModelView came a little odd to me. And I could not find a clear statement of it on internet. On the other side option 2 will bring me away from DRY principle. That's why I wanted to get a clear statement about design decision. — Teoman shipahi, Aug 09 '15 at 02:45
@Teomanshipahi you are correct and I would say that DRY is better... — BillRuhl, Aug 09 '15 at 02:49

score 1 · Accepted Answer · edited May 23 '17 at 12:14

After some more research on this topic; I found out at this question What is ViewModel in MVC? it is clearly stated that:

View models can combine values from different database entities.

As like below;

So now you have data from the Employees and Departments tables in one view model. You will just then need to add the following two properties to your view model and populate it with data:

public int DepartmentId { get; set; }
public IEnumerable<Department> Departments { get; set; }

So I am going with Option 2.

score 1 · Answer 2 · edited Jun 20 '20 at 09:12

The ViewModel pattern is just one of many patterns that fall into the 'Separated Presentation Pattern' bucket.

It's very important that you think about the requirements of your view before designing the ViewModel. For instance, if you have two widgets in your view and every widget has its own ViewModel, composite ViewModel is suitable in the situation, but if the view is just one that uses multiple domain classes, whether you have View model for each one, composite ViewModel is not suitable because it increases the complexity and every change in one ViewModel can break your code.

Thus, based upon your question

As my domain classes I have Person and FavoritePerson classes.

Since I need to show Title of the favorite user in the list (where title belongs to Person class).

It seems to me that composite ViewModel is not a good choice and you should design a new ViewModel.

It is also worth to read the ViewModel Best Practices

ViewModel Structure Decision

2 Answers2