Reputation: 397
I don't think I have seen an example of this, but I also haven't read anywhere that explicitly states that it shouldn't be done. For example, let's say I have some user model with the usual stuff like first name last name etc:
public class UserModel
{
private int userID;
public int UserID
{
get { return userID; }
}
public string FirstName { get; set; }
public string LastName { get; set; }
public string MiddleInitial { get; set; }
...
}
If I were to strictly follow the MVVM pattern, would it be allowed to have, for example, a list of some other model
public class UserModel
{
...
public List<SomeOtherModel> SomeList { get; set; }
}
or should models only have simple types?
Upvotes: 0
Views: 1616
Reputation: 49974
Quite simply, yes.
When doing MVVM you need to change your perspective a little. The definition of 'model' isn't the same as MVC, instead it encompasses everything that isn't the view and viewmodel. This means the 'model' is a data entity (i.e. POCO), it includes any services or controllers, it includes business logic, etc:
Model
The model in MVVM is an implementation of the application's domain model that includes a data model along with business and validation logic. Examples of model objects include repositories, business objects, data transfer objects (DTOs), Plain Old CLR Objects (POCOs), and generated entity and proxy objects.
Quoted from the MSDN article The MVVM Pattern
So now that you've changed your perspective, if your question becomes Should POCOs (DTOs) contain other POCOs?, then the answer is still yes.
Upvotes: 4