ПарамонМСУМодель <> Доменная модель
В MVC модель - это именно доменная модель.


ASP.NET MVC Overview

MicrosoftModels. Model objects are the parts of the application that implement the logic for the application s data domain
Во-вторых, я таки не увидел тут domain model.

a_titeevА вооще, домен несомненно это bl в самом чистом виде...
Доменная модель, если говорить нормальным языком.

ПарамонМСУТогда какую логику может содержать автогенеренный класс контекста? Никакую. Что и требовалось доказать.

Автогенеренный класс расширяют - partial class или extensions methods. Можно использовать Service Layer.
Очень плохая практика. Особенно, когда при работе с БД дернешь свойство/метод кастомного частичного класса, а оно не сможет оттранслироваться в SQL. Получается, одни члены транслируются, другие нет, каша. Далее, возникают проблемы при транспорте такого класса куда-нибудь через сервис. Не все типы автогенеренного класса можно прогнать через SOAP, яркий тому пример тип Binary. Начинается мышиная возня, чтобы поменять в дизайнере контекса этот тип на массив байт. Половина кода из-за этого съедет. Через extensions methods это вообще песня - извращение размазывать логику по всему приложению. Service Layer тут вообще как кобыле пятое колесо.
Нормальный человеческий выход - использовать чистые нормальные классы под логику и не заниматься садомазохизмом с автогенеренными классами.

ПарамонМСУНормальный человеческий выход - использовать чистые нормальные классы под логику и не заниматься садомазохизмом с автогенеренными классами.
На самом деле в большинстве случаев так бывает, но это не - ViewModels а нормальные модели домейна , созданные из одного или нескольких классов.
Ну почему это не вьюмодели? Они готовятся под представление, там и оседают до лучших времен. Их всегда если что можно расширить, причем расширить чисто под вью, можно заколотить свойство типа твоего стися с красным колором и прочее. Это и есть вью-модель. Это и есть доменный объект с логикой. О чем я и тылдычу уже бытый час

ПарамонViewModel это модель без логики, для типизации вью
Несусветные глупости.

http://msdn.microsoft.com/ru-ru/magazine/dd419663.aspx Если логика взаимодействия приложения находится в наборе классов модели представления, легко написать тестирующий ее код. В каком-то смысле представления и модульные тесты — разные типы потребителей модели представления. Набор тестов для модели представленияs приложения обеспечивает свободное и быстрое регрессионное тестирование, уменьшающее стоимость поддержки приложения в будущем.

ПарамонЭто - Приложения WPF с шаблоном проектирования модель-представление-модель представления.
Мы про MVC однако :)
Там речь о модели представления, однако мы о ней и говорим. В MVC нет понятия ViewModel, поэтому обращаемся к первоисточнику.
В модели представления априори должна быть логика. Назовем это "DTO", но только с логикой :)

ПарамонМСУВ MVC нет понятия ViewModel, поэтому обращаемся к первоисточнику.
Поэтому, это совсем не та ViewModel что в - MVVM.
Это с какого перепугу она "не та"? Вью модель везде одна :)

ПарамонЯ уже давно наблюдаю желание, сделать MVVM из MVC :)
Не надо, MVC вполне самодостаточен и гениален. Просто чтоб было совсем вкусно, нужно раздетять дата-модель (кодогенерированный контекст) от доменной модели. И будет щастье.