Алексей КТипичная ошибка профессионального дилетанта в области UI: кнопочка задизейблена, пользователь сидит в обнимку с хрустальным шаром и гадает, почему кнопка недоступна. Так нужно делать только в самых очевидных случаях, которых не много.

Про всплывающие подсказки видимо ты не слышал?

Ну не смеши тапки Ленина хоть!

Алексей КhVosttВот ещё пример.

Пользователь жмёт на чужой комментарий "Ответить", и долго, вдумчиво выплёскивает то, что у него накопилось к оппоненту. Но в это время оппонент решил, что человечество к его комментарию пока ещё не готово и удаляет своё творение. Пользователь жмёт "Отправить" и... получает матюки в ответ, дескать ты чё такой тупой, пытаешься отвечать на удалённые комментарии. Хотя можно было предложить пользователю создать новый комментарий с отправленным текстом вместо ответа или сохранить в черновики, или отправить личное сообщение... Это невозможно никак сделать с твоим подходом. Никак. Ошибки надо ловить там где их можно (и нужно) обработать. А не рисовать некий универсальный подход, которым можно только задницу подтереть.Ну с чего ты взял, что это невозможно? Всё возможно, просто ты не знаешь как. :-)

Ну да. Вот едешь ты на велике, и тут раз -- поворот. В твоей версии ты падаешь, размазываешь себе руки-ноги в кровь, говоришь обёрнутое в InfoException «Блееааать... поворот....», поднимаешься, поворачиваешь велик в нужную сторону, садишься и едешь дальше. Отлично, чо

Алексей КhVosttПро всплывающие подсказки видимо ты не слышал? Хинты на невидимой кнопке, ага.

а зачем хинт на невидимой кнопке? нет кнопки, нет проблем. ты же недавно только бузил по поводу того, что пользователь будет недоволен задисейбелнными контролами, речь шла о них. или ты чего там куришь?

Алексей КhVosttа зачем хинт на невидимой кнопке?Да всё, не зачем, забудь.

Эт видимо какой-то новый способ вести дискуссию, можно нести что попало, потом тупо слить. Ну ок, уже забыл.

zzА как надо? Полностью согласен с необходимостью валидации на клиенте, но ведь бизнес-логику может дернуть (в теории) вообще кто угодно. Да хоть пользователь-мерзавец вручную составил запрос. И так получилось, что entity.A > entity.B. Как быть?

Давай пока оставим бизнес-логику в покое. Возьмём пример по-проще.

var result = Model.A / Model.B;

Что делать? Ловить-оборачивать исключения или проверять Model.B на ноль перед выполнением операции? М?

zzЯ за то, чтобы проверить. Проверили, получили ноль. Что делаем дальше?

Даём возможность пользователю исправить 0 на что-нибудь другое. Подсвечиваем конкретное поле, где пользователь "не прав". Может быть даже обойтись и без этого, если логика допускает, при Model.B == 0, сразу записать в result 0. А что делать и "информационным" исключением? Тынкуть пользователя в него мордой?

zzТак проверку мы где делаем, в бизнес-логике? А как сказать контроллеру, что проверка не удалась? Чтобы он как раз и подсветил поле красненьким для пользователя.

Проверка делается на уровне модели. Т.е. за пределами бизнес-логики. Для валидации должны быть предоставлены необходимые для этого инструменты.

Например, регистрация пользователя. Можно плеваться исключением на тему того, что такой логин уже занят, или предоставить метод для проверки доступности логина -- тогда можно сделать динамическую валидацию на клиенте и сообщить пользователю, что логин дескать занят и предложить на выбор другой, прямо во время заполнения поля. Это всяко лучше чем "обрадовать" юзера, что логин занят после того как все поля уже были заполнены.

Сам контроллер конечно не должен заниматься непосредственно валидацией, эти механизмы выносятся на уровень вью-модели, а контроллер лишь является проводником.

hVosttПроверка делается на уровне модели.

Уточню, вью-модели.