Хорошая тема!
всегда интересовал вопрос - как смотрят мс на капчу (или нечто подобное, слабо относящееся к модели) - где её следует проверять?

авторСмотрю многие фреймворки - там наличествует свойство isValid а перед самой отправкой на сервер - Validate
Это же как-то некошерно - зачем себе голову морочить если модель сразу либо примет данные - либо пошлет - и не надо доп проверок!?
гыгыгы! тема попрежнему интересна!
перед самой отправкой на сервер неможет быть isValid/Validate из серверного кода - ПО ОПРЕДЕЛЕНИЮ!
ещё раз спрошу - есть модель - ответ на вопрос в ветке форума! (postid postname posttime and etc) - всё это проверит модель - длина поста высота и т.д.
на форме присутствует капча, которая к модели не имеет НИКАКОГО отношения - однако её нужно проверить - естественный вопрос -
ГДЕ?!

жесть! MVC = Model/View/Controller

По поводу проверок в БД!
Длина поля не должна превышать 50 симв. Мы запулили 150 -
БД запишет 50 из 150 и не рюкнет!
Пользователь будет огорчён ;)

авторкапча должна иметь отношение к модели представления ,

авторДля понимающего архитектора приложения - обычная ситуация (с имплементацией модели представления ).

авторПочитай про MVVM, много полезного узнаешь.
http://ru.wikipedia.org/wiki/Model-View-Controller Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.

Представление, вид (англ. View). Отвечает за отображение информации (визуализацию). Часто в качестве представления выступает форма (окно) с графическими элементами.

Контроллер (англ. Controller). Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.


господа! не нужно уводить разговор в плоскость MVVM! есть конкретный шаблон MVC - придерживайтесь его понятий и представлений, иначе складывается впечатление, что беседа беспредметна!
авторВо-вторых, есть зашивать в саму модель валидацию - кретинизм.
Наиболее частые ошибкиСреднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, валидировал , записывал, а также передавал данные в вид. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.
С нетерпением ожидаю взрыва ваших эмоций и обвинений в мой адрес в глубочайшем непониманим величайшего творения MS! $)))
Чуть не збыл! Оторвите взгляд от творений чужих рук - создайте свой маленький трёхколёсный велик - ИМХО много нового откроется!
Удачи!

авторну и в модель же пишутся только правила валидации домена БД а не ролевые и другие методы валидации - ядумаю вся эта "другая" логика должна быть вынесена на уровень либо среднего звена либо в слой хранимых процедур
оторви взгляд от БД!
Модель имеет отношение к абстрактному хранилищу данных - БД - всего лишь частный случай - это может быть xml, просто файл, выделенная область памяти и многое другое!!!
+ вьюмодели - выдуманная абстракция твоих собеседников - не ведись!

авторот БД никак не могу взгляд оторвать - любуюсь ею каждый день, да и чо там скрывать! - да, люблю я их, люблю)) - все остальное - это вырожденная БД ))
в фс хранится N количество файлов картинок - невпёрлось их кидать в БД!
как прикрутить к модели сие богатсво!?
Размышляй! ;)

авторНет никаких проблем строго придерживаться шаблона MVC, для вилидации модели использовать - сервисный слой, нужно понять что модель это не класс из БД, а совокупность бизнес правил, но есть также логика представления, капча относится именно к ней, ибо представление может изменится и капча там не понадобится, но на модель это не повлияет.
КО!
что представляет собой валидация - чисто с технической точки зрения?!
некий класс, который в состоянии применить то или иное правило к тому или иному значению, сохранить результат на протяжении опр. времени и выдать его по требованию - валидно\невалидно!
использовать этот класс я волен в контроллере (или др. месте) для проверки значения капчи (к примеру), которое не относится к модели, или в самой модели непосредственно!
У меня не возникает желания создавать промежуточный слой для валидации значений модели - я могу это сделать непосредственно в самой модели, НО у меня есть большое желание не пихать в модель капчу, только потому, что её придётся валидировать, бо я в состоянии свалидировать это значение в самом контроллере!

авторЕсли осознаешь разницу между Motorcycle и MotorcycleViewModel, считай голова есть на плечах.
Motorcycle - это модель (доменная модель).
MotorcycleViewModel - это модель представления.
ASP.NET MVC View Model Patterns - ничего не настораживает?! ;)
авторЕсли все дело в капче - пожалуйста, просто иногда валидация включает в себя кучу разных сервисов, моделей и прочего, так что когда контроллер распухнет то придется задуматся.
да...да... не нужно пугать народ кучами всего всего!
конкретно -
POST текстового поля с сохранением в БД (так обожаемую некоторыми персонажами ;)
1. броузер посылает значение aaa=mmmmm
2. сервер запрашивает страницу, которая по опр. правилам вызывает опр. метод класса контроллера!
3. этод метод вызывает метод класса модели, передавая туда значение aaa=mmmmm
4. ВАЛИДАЦИЯ происходит именно там и, в зависимости от true\false записывается\незаписывается значение ааа в БД!!!
5. на странице ПРЕДСТАВЛЕНИЯ смотрим класс error - не пустой - значит выводим ошибку пользователю - пустой, значит всё ОК - ждём от пользователя дальнейших действий!
GET
1. броузер запрашивает страницу по адресу передавая туда GET значение id=1
2. сервер запрашивает страницу, которая по опр. правилам вызывает опр. метод класса контроллера!
3. этод метод вызывает метод класса модели, передавая туда GET значение id=1
4. ВАЛИДАЦИЯ происходит именно там и, в зависимости от true\false выдаёт нам значение из БД!!!
5. контроллер передаёт полученные данные представлению, которое отрисовывает данные в нужном порядке!

Где в этой схеме появилась модель представления !?
там где мы захотим в GET перевернуть строку с ног на голову?!
честно - меня поражает ваша доверчивость - МС кормит вас слоями, архитектурой и всякой требухой - вы хаваете и рады непомерно...

авторНичего. А что должно настораживать? В классический механизм тупо добавлена новая абстракция для расслоения зависимости от доменной модели.
гыгы... ну возми карандаш и пририсуй к классическому механизму новую сущность - модель представления - незабудь выложить сюда свою схему - посмотрим на связи и зависимости! ;)
автордальше курим смысл типизированного представления , и как можно заполнить его данными из других источников, не меняя тип и структуру.
YES!!!
вот мы и добрались до сути вопроса - ещё один уровень абстракции!
да нах оно не нужно! есть руки, есть голова! есть набор данных получаемый из контроллера - этого вполне достаточно, для отрисовки этих данных на стр. представления!
ОСТАЛЬНОЕ - приведёт к копированию модели WebForms - и в довольно обозримом будущем будет признано ошибкой, тк зашьёт логику исполнения так глубоко, что никакими клещами будет не выдрать!

ты будешь зажат рамками серверного кода и отсутствием что либо изменить - по определению!
ИМХО - для реализации козырного WEB-проекта - возми в руки учебник по HTML, CSS, javascript + какой-нибудь серверный ЯП - этого хватит с головой! ;)

ПарамонНачнем с понимания того что "mmmmm" это поле, которе находится в системе платежного сервиса,
дальше курим смысл типизированного представления, и как можно заполнить его данными из других источников, не меняя тип и структуру.
забавно!?