Некоторые и в представление гвозди забивают.

ПарамонВ идеале котроллер вообще не должен содержать бизнес логику, а только осуществлять интеракцию между моделью и представлением.
В идеале, да.

http://ru.wikipedia.org/wiki/Model-View-Controller Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида).

Многие использую модель как маппинг БД-объектов, это не правильно. Модель (модель представления) - это отдельный класс, отвечающий именно за логику.

ПарамонМодель - это слой логики, который может содержать классы маппинга, сервисы, репозиторий etc.

авторМодель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.
Может, но это негибко и не правильно. Проблемы начинаются тогда, когда нужно расширить модель под представление. Править кодогенерированные прокси нельзя. Другая задача, когда представление использует несколько маппинговых классов и еще доп. логику. Без «модели представления» не обойтись.

ПарамонЭто да, но такая модель не часть бизнес логики, бо ее не получится использовать с другим типом UI.
Почему? Такие классы можно использовать в любом UI.

ПарамонЕсли другой UI идентичный первому. Эти классы обычно делаются под конкретное представление. (это про тупой ViewModel)
Да, именно об этом и речь.

ПарамонЯ говорил про класс, который может содержать логику представления.
Почему нельзя заложить логику в модель представления ? По сути модель представления и является "моделью" в терминологии MVC. Вот логике там и место.

ПарамонМСУПо сути модель представления и является "моделью" в терминологии MVC. Вот логике там и место.
Само слово "модель" там путает, к "Domain model" ViewModel не относится.
Модель не должна зависеть от представления, в этом весь смысл модели.
Не правильно. Доменный объект представляет и реализует бизнес-логику программы. Модель представления - это как-раз доменный объект , а не доменная модель :)

...Доменные объекты инкапсулируют всю необходимую для программы информацию об объекте предметной области. Так, например, реальный сотрудник может иметь фамилию, имя, отчество, пол, возраст (модель предметной области), но, если в программе используются только фамилия и имя, то именно они будут включены в качестве атрибутов доменного объекта (уровень объектов предметной области).

То есть мы имеем слой предметной области (другими словами).

ПарамонМодель не должна зависеть от представления, в этом весь смысл модели.
Разумеется. И она не зависит от представления.

Русским языком модели представления .

ПарамонЭто может быть, но модель предметной области не может вернуть к примеру [style="color:red;"], в то время как модель представления - да может.
А не надо возвращать [style="color:red;"]. Сделай отдельное свойство типа Color и возвращай Color.Red. А в представлении конструируй нужный стиль на основе нормального типизированного члена модели представления. Не стоит настолько глубоко заколачиваться к представлению.
Тогда и UI, о котором ты говорил ранее, можно будет сменить.

ПарамонМодель представления в виде ViewModel - это просто типизация конкретного вью.
Модель представления в виде ViewModel - это модель со всеми вытекающими. Там место логике. В MVC в качестве модели многие подпихивают отображение БД, что не верно.

Итак, что имеем в ASP.NET MVC:

DAL (контекст / репозиторий) с автогенеренными отображениями объектов БД на классы (таблицы, вьюхи, хранимые процедуры, функции)

Контроллер. Тут всё понятно.

Представление. Тут всё понятно.

Модель. Она же DTO. Она же модель представления. Место для логики и прочим плюшкам. Может объединять в себе сложную логику с Master-Detail-Detail-...-Detail связками и прочее прочее. Те же Color свойства, да что угодно.

P.S. Не нужно путать автогенеренные классы контекста с моделью. Это разные вещи.