Где производить валидацию данных в контроллере или в модели?

Проводи, где тебе удобнее. Ты программист или копипастер?
"Где удобнее" подразумевает, то, что ты не будешь после этого делать больше костылей, где ты будешь смотреть на код и он будет радовать глаз и ты будешь кайфовать, смотря на валидацию.

 

Валидация это принадлежность модели. Только она знает что ей нужно и в каком виде.

Но вызывать валидацию должен тот кто пользуется моделью, т.е. контроллер.

Здесь форма выступает простейшей моделью. Вместо нее(или после нее) может быть Domain модель.

PHP:

1.  
2. <?php
3. class UserController extends Zend_Controller_Action {
4.     public formAction() {
5.         $frm = new My_Form();
6.         if ($this->getRequest()->isPost()) {
7.             if ($frm->isValid($this->getRequest()->getPost()) {
8.  
9.             }
10.         }
11.     }
12. }

Естественно, если кто-то другой(не контроллер) будет использовать нашу модель, то и он может использовать валидацию модели.

 

зависит от сложности валидации, если сложная - то в модели, если простая - то в контроллере

 

проверяет модель товаров

 

[vs]
мвц чисто правильно никогда не делают, иначе бред будет, что ты даже любые самые мелкие проверки и действия обязан будешь выносить в модель

 

Нет одного решения. Обычно проверки размазаны - часть в модели, часть в контроллере. В модели сидят проверки относительно данных самой модели и вызываются они обычно на (условно) onBeforeSave событии. Как правило в фреймворках есть уже готовые решения для создания валидаторов методом описания условий.

А вот проверки на связность данных - в контроллер. Например, объект фирмы имеет связь с объектом города - тут никак не запихнуть проверку города в модель. Для себя стараемся придерживаться такого правила - модель не должна ничего знать про другие модели. Т.е. внутри модели не должно быть никаких созданий/вызовов объектов других моделей. Следует это из правила уменьшения сцепок.

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

Как правило, условно можно разделить модели на прикладные и самодостаточные. Например, фото - это исключительно прикладная модель, с которой мы можем работать изнутри той модели которой эти картинки нужны. А вот, к примеру, модель города - это уже самодостаточная модель, которая связана с другими - работа с ней должна идти в контроллере. Опять же сложно описать критерии - когда можно, когда нет... все порой на интуиции, которая является следствием опыта.

В случае изображений мы поступили так: есть некий класс "коллекция файлов", который по сути является неким датамапером для работы с изображениями. Он умеет по имени модели строить путь и возвращать набор объектов изображений, а так же умеет делать "save" в т.ч. из uploaded фалов. Для каждой модели, которая работает с изображениями есть соответствующая модель картинки (наследованная от общей, конечно) - всякие проверки на форматы, ресайзы и т.д. уже в ней. Т.е. по сути в модели товаров у нас только Toolkit::instance()->getCollection()->uploadFiles("МодельИзображенийДляТоваров"). Колекция же по сути делает для каждого файла new "МодельИзображенийДляТоваров" и потом этому объекту save(), а тот уже на save() делает все, что нужно.

 

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

 

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

 

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

хотя некоторые моменты допустимо проверять в контроллере

 

мясо надо)
что за модель? что у нее за данные, которые должны быть корректными на входе (даже скорее перед входом)? используется еще где-то? как обойти дублирование кода ("зачем платить больше"), если модель используется еще где-то и данные снова должны быть корректные? менялась ли модель в процессе разработки? если да, как вы отслеживали, что в контроллере и других местах использования модели все данные валидировались?

извиняюсь, что много вопросов.

 

Да ниче - ответ один, как для тебя так и для sylex - я юзаю что-то типа command или вроде точнее reactor, поэтому как таковое понятие контроллера у меня размыто немного и код не дублируется, просто один контроллер обращается как бы к другому... В принципе это уже не совсем контроллер с ваших точек зрения, но кроме как он больше никто делами контроллера не занимается.... От така фигня ))

 

hardj
Все на эксепшенах и все в моделях. Потому что модель используется и внутри других моделей и в кроновских скриптах и в веб-сервисах. А контроллеров там не будет. Так что вот и подумай.

 

hardj
пока не привели пример с необходимостью валидации данных в контроллере, можешь валидировать всё в модели)

 

Проверять ты можешь где угодно.
Но метод валидации предоставляет модель.
Только она может знать что ей нужно и в каком виде.

PHP:

1. <?php
2. class UserController extends Zend_Controller_Action {
3.     public function updateAction() {
4.         $mdl = new Model();
5.         if (!$mdl->isValid($this->getRequest()->getParams())) {
6.             die("Все пропало шеф!");
7.         }
8.     }
9. }

глупости какие

Bingo!

 

b]Simpliest[/b]
По-моему в кроновском скрипте нет ни url ни request, но конечно можно их искуственно создать, если по-другому никак.

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

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

PHP:

1. <?php
2. $model= new Model();
3. $model->a= $argv[1];
4. $model->doSomething();
5.  

Если в doSomthing() у тебя модель ожидает, что в ней провалидированные контролером данные, считай ты приучил ее к контролеру. А зачем тебе тогда мвц?

 

кто такое сказал? Это доказано как закон? Или может аксиома?
Без всяких упрёков к тебе, но поначитаются авторитетных авторов, которые навяжут вам свое мнение, а потом рассказывают, что да как надо. Всё программирование заканчивается на Макконнелле. Выше уже специализация.

 

Иногда правильно и в контролере. валидация тоже бывает разной. есть валидация уровня бизнеслогики, есть валидация уровня интерфейса. но это совсем другой случай.

например если есть модель, которая делит два числа
class DivModel{
fnc div(inx x, int y){ }
}

если в скрипте то все понятно. если эту же модель использовать через веб-нитерфейс, то появляется дополнительная валидация.

валидация у!=0 - это валидация уровня бизнеслогики и она правильно делаться внутри модели, а не в каком-то контролере. А валидацию x и y - это два чиста, а не две строки 'qwerty' можно/нужно делать внутри контролера, потому что это не относится к бизнеслогике.

и все везде всегда на исключениях

 

URI - это адрес ресурса с параметрами и ничего более.

чем отличается
GET /localhost/cli.php?param=1
от
php.exe D:\www\cli.php param=1

Да ничем. Единственное что PHP для тебя распарсит параметры и создаст $_GET/$_POST/$_COOKIE
Для CLI у тебя эти параметры будут в $argv, а в $argc будет их число.
Все.

Слушай, завязывай а? Я терпеть не могу глупости.

Модель вообще ни к чему не приучена. Она получает данные и может с ними что-то сделать.

PHP:

1.  
2. <?php
3. $mdl = new Model();
4. $mdl->isValid($argv);
5. $mdl->isValid($_POST);
6. $mdl->isValid(array('param' =>1));

Но о других моделях она знать ничего не знает и не должна.

Поэтому этот паровоз как ты изволил выразится вызван одним простым принципом DRY - don't repeat yourself
Дабы не страдать маразмом и не прописывать связи и бизнеслогику отдельно для CLI версии, пишется вот такой раннер
и используется уже готовый код.

 

Это логика сказала. Вы ее не слушаете?

Кроме меня самого никто не знает люблю я картошку-фри или бешбармак.
Поэтому и говорить нравится/ненравится valid/not-valid - мне, а не тебе.
Ты можешь у меня спросить, но не более того.
Потому что завтра вкусы у меня изменятся, а ты по-прежнему будешь уверен что бешбармак и блондинки это то, что мне нужно.

Ты заблуждаешься.

Знаешь в чем твоя проблема?
В том, что ты наивно полагаешь, что мне можно навязать мнение одним лишь авторитетом.

Я не читал ни одной книги по программированию за последние 17 лет, но с логикой я дружу.
И мне будет плевать на Фаулера, Макконела и других, если они начнут нести чушь.

И не надо говорить глупости, я этого не люблю.