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

Question

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?

Answer 1

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.

Answer 2

Split them. Keeping them together violates the single responsibility principle, which, put simply, is that a class should have one reason to change. If this model serves both the register page and login page it is doing too much. If the login page changes, why should the register page be potentially affected by it? It shouldn't. It tightly couples the register and login pages in a non-obvious way.

This may not seem like such a big deal for register and login pages, but what about other pages? It'll get really tempting to just reuse a model because it happens to have all the fields you need rather than write a new model class. And then eventually you end up with the GodModel class that holds properties for everything in the system. You never need to write another model, but heaven help you trying to use it.