Тогда их нужно валидировать в базе :-) Кстати, валидация данных вне места их использования - это тоже decoupling! Так что получается, что все задачи проекта должны решаться в одной модели.

Я против того, чтобы валидировать данные в модели. Точнее я за применение “инверсии зависимостей” - т.е. вынести валидацию во внешний класс и при инстантировании модели передавать соответствующий валидатор в модель.

Теперь по существу. Перед данными модели, работающей с БД, всегда ставиться несколько вопросов:
1. Может ли она сохранить эти данные (технические ограничения);
2. Должна ли она сохранить эти данные (логические ограничения зависящие от контекста использования)
3. Может ли она использовать сохраненные данные при выполнении данной задачи.

Простой пример, задача “Подсчитать среднюю сумму одного заказа в интернет магазине” рассчет такой Sср = Sобщ / Nпок, где Sср - средняя сумма, Sобщ - общая сумма покупок, Nпок - количество покупок.
Допустим в каком-то месяце продаж не было. Это значит Sобщ и Nпок имеют нулевые значения, а это значит что ответы на вышестоящие вопросы будут следующими:
1. Может ли модель сохранить данные? - Да
2. Должна ли модель сохранить данные? - Да
3. Может ли модель использовать сохранненные данные? Нет. Делить на ноль нельзя!

Ответы на вопросы 1,2 никогда не будут контролироваться моделью, по крайней мере до тех пор пока будет использоваться БД. Я бы сказал, что модель успешно может отвечать только на вопрос 3, причем в разных случаях ответ на этот вопрос может быть разным.

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

Хм… на мой взгляд, тут 2 модели: “Комментатор” и “Пользователь”. Каждая модель валидируется по-своему, но хранилище могут использовать общее. Как-то так…

Простой пример:
Во фронтенде новый юзер при добавлении комментария, указывает ник. Валидация для ника только буквы + длина ограничена.
В баккенде при использовании этой же модели я хочу разрешить админу использовать еще и цифры пробелы и т.д. При подходе валидации данных в модели, мне придется писать костыль который скажет что надо применять другую валидацию для этого поля. А если таких различных мест много в проекте, то у нас получится очень странная модель которая пытается реализовать всю валидацию необходимую для проекта в целом.

Набором валидаторов применяемых в конкретной ситуации может выступать отдельная модель-валидатор. Которая сможет проверить данные в соответствии со своими заданными правилами валидации. Эту модель можно применять для валидации других моделей-данных. Вот как то так я себе все это представляю.

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

напиши мне на емейл, пообщаемся в скайпе.

$user = new User;
$user->name = ”;

if (!$user->save()) { // save запускает валидацию
print_r($user->getErrorMessages());
}

Как-то так. В общем, если интересно, могу показать свою ORM :) Вообще, ищу единомышленников для создания ORM ;)