Сперва опишу контекст. Кому многа-букф, можно сразу перейти к вопросу в конце поста.

Как всё случилось:
Был функционал по вводу данных. Данные хранились (и хранятся до сих пор) в нескольких таблицах, связанных либо 1-0..1, либо 1-0..*, по-разному. В связи с этим первоначально всё было реализовано так, что вначале вводим основную запись, сохраняем её в БД, потом вводим зависимые записи и сохраняем также отдельно со ссылкой на основную запись. Для примера давайте возьмём сущность пользователя с несколькими адресами. Сначала ввели пользователя, потом вводим его адреса.
Юзеры начали роптать, что это не стыкуется с их ощущением бизнеса — они хотят сразу всё ввести и сохранить одним махом. При этом сама вся вводимая сущность довольно объёмистая и на её ввод может уйти прилично времени (за которое может произойти всё что угодно) и автоматически встал вопрос о том, что в процессе ввода надо делать временные сохранения, чтобы в случае чего можно было вернуться к ранее создаваемому объекту.
Поскольку надо было делать довольно резво, решили обойтись флагом временности в основных таблицах. Т.е. теперь сущность вставляется в БД сразу вначале создания и все зависимые объекты сразу могут сослаться на неё. В конце редактирования (при нажатии на финальное "Сохранить"), флаг временности убирается и сущность становится полноценной.

Из негатива:
Пришлось убрать всю обязательность полей в БД и с атрибутов сущностей Entity Framework, поскольку временные сущности могут быть сколь угодно неполными. По факту серверную валидацию даже и не делаем (оставили только клиентскую), но об этом не принято говорить на людях.
Во всяких запросах пришлось понавтыкать проверку того, чтобы временные сущности не подхватывались.
Код сохранения сущности стал довольно сложным (если временное сохранение, то так, а если нет, то эдак).

Что хочу сделать:
Создать отдельную сущность (чтобы окончательно всё запутать) для временных объектов — по структуре, сильно упрощённую модель настоящих объектов. Все операции с временными сущностями будут происходить в своём мирке, а при переводе в постоянные таблицы будут выполняться все проверки (т.е. опять верну обязательность полей в БД и в модели EF).

Где вижу предстоящие сложности:
Валидация. Дело в том, что временная модель не должна будет содержать никаких атрибутов Required и т.п. Но контролллер и вью будут оперировать в первую очередь с временной моделью. При переводе временной модели в постоянную я могу задействовать проверки, но вся эта автоматическая asp.net mvc валидационная лабудень будет по умолчанию в ModelState писать названия свойств постоянной модели. И вью (работающее со временной моделью) не будет подкрашивать соответствующие поля.
С подобной проблемой вероятно должны были сталкиваться те, кто на постоянной основе разделяет ViewModel и DomainModel. Хотел узнать, есть ли какие-то наработки в том, чтобы связать эти слои не только от View к Domain, но и обратно? Т.е. чтобы валидационная информация из Domain'а нормально применялась в презентационном слое.

Вопрос вкратце:
Если вы разделяете ViewModel и DomainModel, то как при этом View получает и отображает ошибки валидации по полям Domain-модели?

Сейчас смотрю AutoMapper, но что-то как будто не умеет он этого...