Q:

If model in MVC serves multiple purposes (views), should it be split to multiple models?

In MVC (I'm using Spring, although it's not relevant to the discussion) I have a following model:
public class User {
    private Long userId;
    private String username;
    private String password;
    private String passwordRepeat;
    private String email;
    private boolean rememberLogin;
    /// ctors, setters and getters [...]
}

This model is used during both registration and login and therefore contains a sum of fields for both purposes. In particular - passwordRepeat is completely not relevant during login and vice versa - rememberLogin is unused during registration. It was all fine up to the point when I started adding validation (javax.validation) as annotation to the fields. For example I want to put constraints on passwordRepeat so that it is not null and witin given size range, however it will inevitably be null during login validation.
Should a model like this that serves multiple purposes be split into multiple objects (for example: UserLoginData, UserRegistrationData and User) or is there a better way of approaching this?

A:

There are essentially two approaches for this sort of thing.
Approach #1. Single model
You write a single model, User, and several actions that go with it, e.g. Add, Edit, Delete, List, and View. All the views would use the same model (or perhaps a List<model>. This kind of approach is what you get when you use the scaffolding wizards in Visual Studio and is OK for basic CRUD operations without any peculiarities.
Approach #2. View Model
Under this approach, you write a model that is specific to the view. When you do this, you can refer to the model as a ViewModel. Generally speaking, the model in this sort of design is acting as a container for an action, not an entity; you can think of it as the equivalent of a paper form that a person would fill out when formally making a request of some business unit.
So you'd have to ask yourself, is the act of registering as a user more similar to the CRUD action of "Add domain object user," or is it more like "Create and submit a request to register" ?  
In my experience, if a user is registering to use a web site for the first time, that is more like a request that a CRUD action, and it should get its own ViewModel. If the user has already registered, but maybe is setting up subusers (i.e. people with shared access), that is more like a CRUD operation and maybe you could get away with a single model class.

