Здравствуйте, Neco, Вы писали:

N>Что хочу сделать:
N>Создать отдельную сущность (чтобы окончательно всё запутать) для временных объектов — по структуре, сильно упрощённую модель настоящих объектов.
Так и надо делать. Эти объекты — модель для пользователей, которые осуществляют ввод данных. Как им удобно, так эти объекты и должны принимать данные.

N>Все операции с временными сущностями будут происходить в своём мирке, а при переводе в постоянные таблицы будут выполняться все проверки (т.е. опять верну обязательность полей в БД и в модели EF).
Проверки должны выполняться раньше — сразу после ввода данных. Тогда приложение будет доверять этим данным на 100%, потому что мусор не прошёл фильтр.

N>Где вижу предстоящие сложности:
N>Валидация. Дело в том, что временная модель не должна будет содержать никаких атрибутов Required и т.п. Но контролллер и вью будут оперировать в первую очередь с временной моделью. При переводе временной модели в постоянную я могу задействовать проверки, но вся эта автоматическая asp.net mvc валидационная лабудень будет по умолчанию в ModelState писать названия свойств постоянной модели. И вью (работающее со временной моделью) не будет подкрашивать соответствующие поля.
Вот именно. Если сразу видна корявость этого подхода, зачем на него тратить время? Пользовательские структуры данных должны содержать необходимую валидацию — тогда, если данные прошли валидацию, приложение может работать с этими структурами дальше.

N>С подобной проблемой вероятно должны были сталкиваться те, кто на постоянной основе разделяет ViewModel и DomainModel. Хотел узнать, есть ли какие-то наработки в том, чтобы связать эти слои не только от View к Domain, но и обратно? Т.е. чтобы валидационная информация из Domain'а нормально применялась в презентационном слое.
Смотри выше. Приложение должно доверять самому себе и не содержать мусорной логики на каждом шагу. Проверки на корректность и безопасность — забота других слоёв, внешних по отношению к ядру приложения.

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

ViewModel отвергается до тех пор, пока из неё нельзя получить корректную DomainModel.