A: 

The fundamental issue here seems to be one of the following:

  1. Contextual validation rules are being expressed as invariants
  2. Entities with unsatisfied invariants are being prematurely created/validated

I would suggest that you don't attempt using Model Binders to instantiate and validate types for which all invariant information isn't obtainable from the Http request. In the case of LogOn, the only information you have is the user's name and password. Therefore, LogOn shouldn't expect a User type, but rather the username and password, perhaps encapsulated in a Credentials type.

Derek Greer
In my example, it’s very easy to separate it into 2-3 data fields. However, in real world application, it's impossible to separate it. Because you cannot ensure that if you change some field name in the database, it will not affect any views. Moreover, validation rules must be duplicated too that bring complication to me for maintenance it.
Soul_Master
You didn't give any detail on how your domain model relates to your database, but they shouldn't be coupled such that changes to field names within the database affect your views.Concerning validation, you can still centralize your rules by encapsulating them within validators if needed. In the log in scenario, however, best practices dictate that minimal feedback is given if the user provides incorrect criteria. The validation for username and password will also generally be different between log on and user creation scenarios.
Derek Greer
My core problem is I don't want to write some JavaScript or any client script for validating some silly logic (some logic that don’t related with other rows or object) like require field, string max length or whatever. Because it can't check that is valid or not at build time. This concept is much like validation. As your suggestion, I do not like to create a rule validator because its logic will be written in the data access layer. Thanks. PS. error message will be selected in view layer depends on what error occurs.
Soul_Master
I'm not sure what you mean by your JavaScript comment, but what I'm suggesting is that removing contextual validation concerns from your business object need not cause duplication if it is encapsulated within a validator. You should explore some of the validation frameworks available such as the Validation Application Block, NHibernate Validator, etc. None that I've seen have anything to do with being coupled to a data access layer.
Derek Greer
Additionally, concerning your comment about the error message being selected depending on what error occurs, the scenarios you've described should require contextual validation. For example, log on might have an error message of "The username/password supplied were incorrect" while user registration/password change might have an error message of "The password must be between N1 and N2 in length, contain N special characters, ..." This can't be achieved by expressing validation rules as invariant conditions on your business object.
Derek Greer