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

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

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. Не нужно путать автогенеренные классы контекста с моделью. Это разные вещи.

ПарамонМСУМодель. Она же DTO. Она же модель представления.

Это три совершенно разные вещи, причем у каждого своё предназначение. )
Это одно и тоже в концепции MVC.

ПарамонСам ссылку дал :)
авторView Model отличается от Domain Model тем, что он предназначен не для представления предметной области, а лишь для передачи данных из контроллера в представление в удобной форме
Ты опять меня не слушаешь и второй раз наступаешь на те же грабли :) Причем тут доменная модель ? Речь о доменном объекте . В концепции MVC: модель можно считать моделью представления == оно же DTO == оно же доменный объект.

В MVC нет понятия модели представления. Эта абстракция позаимствована из MVVM. Чтобы было легко в будущем - используем вместо модели - модель представления. А в частном случае это будет одно и то же.

ПарамонМСУТы опять меня не слушаешь и второй раз наступаешь на те же грабли :) Причем тут доменная модель? Речь о доменном объекте
Доменная модель кабэ содержит доменные объекты :)
Вот именно, так причем тут какбэ модель представления? :) О ней речь.

ПарамонМСУВ концепции MVC: модель можно считать моделью представления == оно же DTO == оно же доменный объект

В концепции MVC: шкаф не становится табуреткой :)
Еще раз прочитай статью. Раз пять прочитаешь, начнешь понимать.

pationконечно же нет модель это намного больше чем просто дэтэошка и больше чем просто конкретно взятый доменный объект
не надо спутывать понятия
Сними розовые очки, это всё то же самое. DTO - это точно такой же отвязанный слой. Модель представления - такой же отвязанный слой. Не вижу принципиальных отличий. Ты видишь?

ПарамонМСУЕще раз прочитай статью. Раз пять прочитаешь, начнешь понимать.

Тогда прокомментируй это:

авторView Model отличается от Domain Model тем, что он предназначен не для представления предметной области, а лишь для передачи данных из контроллера в представление в удобной форме
Еще раз, про доменную модель речи не идет. Сколько мне раз это нужно повторить? Модель представления и доменная модель - это как камень и гора.

ПарамонМСУМодель. Она же DTO. Она же модель представления.


МСУМодель представления и доменная модель - это как камень и гора.
Противоречие? :)

нет :)

Модель <> Доменная модель

pationМСУНе вижу принципиальных отличий. Ты видишь?
ы сам это придумал или вычитал где-то? DTO в общем случае не содержит да и не должно содержать никакой бизнес логики
DTO не должен содержать бизнес-логики, модель представления - может. Только в этом и отличие.
Для большинства случаем модель для представления также не содежит логики, тупой маппинг с БД. В чем тогда различие?
Для большинства случаев модель представления будет являться банальным DTO, о чем я и писал.

pationТвоя тупая упёртость - это точно такой же отвязанный слой.
Тупое непонимание, как в соседнем форуме про Action, такой же отвязанный слой?

pation, ты как всегда мимо кассы, еще раз цитирую

http://merle-amber.blogspot.com/2009/04/aspnet-mvc.html Самые внимательные уже наверно увидели сходство паттерна View Model с DTO (Data Transfer Object). И сходство действительно есть, причем значительное. И там, и там - проекции данных для передачи куда-то. Только, в отличие от DTO, которые могут передаваться как угодно далеко, хоть на деревню дедушке, View Model объекты передаются всего лишь по соседству в представление. Так что можете пользоваться этой аналогией, если вам так будет проще понять смысл View Model и его назначение.

Так что можешь потихоньку начинать убивать себя об стену, так же как и с Action.

pationэто основное принципиальное отличие, тем более в разрезе этого топа.
Я про частные случаи, коих сплошь и рядом.

pationя думал ты программы пишешь, для HelloWord вообще нет смысла связыватся с MVC
Ситуации разные бывают. Я принципиально назвал модель представления = DTO, и ничего тут сверхужасного нет. Ты прицепился к словам и начал полемику про то, какое небо голубое.

ShSergeМСУ, Давай договоримся раз и навсегда. Таких придурков, типа тынц , чтобы здесь и не пахло. Понял?
1. Почему он "придурок", поясни? Человек свободными словами описывает своё понимание.
2. Почему запрещено давать ссылку на блог? Объясни.

pationЭто всего лишь частное упрощённое субъективное суждение блоггера
Разумеется, и я с этим суждением солидарен. Ничего большего.

pationЗаканчивай уже рефлексировать по этому поводу=))
Это я так, чтоб к словам не цеплялся. А то начал менять троллить по DTO :)

pationМСУЯ про частные случаи, коих сплошь и рядом.
нельзя рассматривать общую концепцию в разрезе частных случаев
Всё в мире относительно, можно и так, можно и эдак.

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


ASP.NET MVC Overview

MicrosoftModels. Model objects are the parts of the application that implement the logic for the application s data domain

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

А вот все модели представлений можно назвать доменной моделью.

ПарамонМСУМодель <> Доменная модель
В 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 в самом чистом виде...
Доменная модель, если говорить нормальным языком.