Shocker.ProНо уровень контроллер/вью ничего не знает о DAL-е, он делает валидацию только того, что он может сделать без DAL-а, то есть полноценной проверки там нет.

Немного неправильное утверждение. Уровень контроллер/вью ничего не знает о деталях реализации DAL, но формат данных между DAL и вью/контроллером должен быть согласован по принципу DAL > View, но не наоборот.

Shocker.ProБизнес-логика делает серьезную проверку с привлечением DAL-а. При этом, ты говоришь о том, что бизнес-логика должна валидировать повторно такие вещи, как, например, допустимая длина строкового поля.

Бизнес-логика должна валидировать по максмому. Я говорю, что раз в выпадающих списках у тебя только тот набор данных, который позволен для выбора пользователю, проверять этот выбор в контроллере -- не обязательно, так как штатная ситуация подразумевает, что выбор будет верен. Не штатные ситуации, такие как злой умысел, или резкая смена прав пользователю админом во время редактирования формы, их нужно предусматривать на уровне бизнес-логики. Тащить всё в контроллер -- не нужно. Контроллер должен быть тупым.

Shocker.ProДумаю, тут все-таки есть место для спора о том, зачем тогда валидировать на уровне контроллера/вью? Ок, механизм выплевывания исключений при ошибках валидации я тоже не поддерживаю, но бизнес-модель так или иначе возвращает стандартные ошибки валидации типа "такое название папки уже существует, выберите другое название". Она также может вернуть и ошибку длины строки.

Ещё раз, разбери ситуации на штатные, и не штатные. «Такое название папки уже существует» — это вполне штатная ситуация и должно валидироваться контроллером (вызов проверки на дублирование имён из DAL ещё до попытки изменения/вставки записей). Штатная, потому что пользователь ___может___ легко ввести дублирующееся название. Проверка на дубли должна быть включена в валидации контроллер/вью, может быть ты захочешь использовать AJAX и подсвечивать поле ввода сразу же после окончания ввода, поэтому не стоит для этого задействовать механизм валидации DAL. Но на уровне DAL валидация должна быть повторена перед изменением.

Не штатная ситуация -- это выбор из выпадающего списка элемента, которого там быть не должно при нормальной работе. Это валидировать контроллером не нужно, подразумевается, что в 99% случаев ошибки не произойдёт, так как список для выбора фильтруется зараннее. А вероятность ситуации, что к моменту выбора пользователем что-то поменяется (позицию для выбора удалят, или админ поменяет права пользователю) — слишком мала. Но на уровне DAL всё должно быть скурпулёзно проверено, независимо от вероятности ошибки.

Shocker.ProТак вот, собственно, может есть какие-то приемы унификации таких проверок.

Просто проверь в DAL содержимое изменяемых данных на корректность в рамках транзакции, если что-то не так, выбрось исключение, так как попадание в DAL некорректных данных -- это исключительная ситуация однозначно. Архитектуру исключений рассматривать не будем. У нас для таких ошибок есть отдельная ветка, которая совершенно однозначно расшифровывается фильтром контроллера, а на клиенте механизм таких ошибок обрабатывает сообщения с ошибками универсально, подсвечивая, если надо какие-то поля (соответствие с полями задаётся в момент отражения, но это всё просто сахар).

skyANAhVostt, а что такое некорректные данные с точки зрения DAL?
Ты ему сейчас насоветуешь, он бизнес-логику в DAL засунет.
А потом из другого места данные в базу не сможет залить из-под админа :)

Да, согласен, правильно проверять корректность не в DAL, а в слое бизнес-логики. Напутал пока писал.