View model structuring best practise

Question

What is the preferred convention for structuring view model properties? It is better to use generic or more specific property names?

Let's have a user, the page where this user will be displayed should be altered by user's permission. The view model could be written in two different ways:

{
 userName,
 userEmail,
 isAdmin // show/hide controls according the value of this property
}

or

{
 userName,
 userEmail,
 enableDeleteBtn, 
 showLogData,
 // many more show/enable properties which are set according user's permissions
}

The first approach seems to smaller and easier to write, but it's less generic and the logic of displaying/hiding controls have to be changed if for example new type of user role will be introduced.

Answer 1

Whether a user role, such as admin, is allowed to see the some data (such as logs) is a business rule.

Business rules belong to the domain model.

The values of show/enable properties calculated within the domain model need to make it to the view somehow.

A viewmodel is an object designed just for that. It will contain pre-calculated values for things and decisions that should not be calculated in the presentation layer.

Answer 2

I prefer the first one. Otherwise you are tying your view model to the implementation of your view, ie. putting display logic, which should live in your view into your view model.

Also the first shows why the delete button is enabled ie. it's in the language of the domain. If you look at the view and have to go through and track down why it is enabled somewhere else, then you have a bad abstraction.

• Marian Ban: Yes but wouldn't be then my view tightly coupled with a business logic? should the view know anything about the admin users?