Помогите с сервисным слоем

[whirlwind]

Ну что такое репозитарий? Я лично отношу к репо объекты которые реалтайм хранятся, а (дата)маппер которые персистент в базе. То есть разницы особой нету между репо/персистент. Единственно, что персистент надо запросить сначала. PS. думаю логично

 

[grigori]

whirlwind, что значит "с подпиской на invalidate" ?

imho капчу надо проверять в модели user, она - данные, необходимые для создания записи,
и картинку при аплоаде тоже надо проверять в модели, хоть и лежит она в файле, а не в поле объекта

наборов правил в модели может быть множество для разных ситуаций
например, в yii правила валидации пишутся

		return array(
			array('title,category_id,status,description', 'required','on'=>'create'),
			array('id,title,category_id,status,description', 'required','on'=>'update'),
			array('title', 'length', 'max'=>255),

 

[korchasa]

grigori
Каптча не является частью пользователя, это кусок конкретного UI. Она не обязательна для создания пользователя.

 

[grigori]

да, если у тебя есть несколько UI, надо создавать отдельную модель для обработки формы, которую использовать как источник данных для объекта модели user
но у сайтов один UI, это просто плодить сущности

идея валидации данных в контроллере мне нравится еще меньше

 

[korchasa]

но у сайтов один UI, это просто плодить сущности

Если в админке можно создавать пользователей, то UI уже 2. Если модели покрывать тестами, то 3. Если у него есть внешнее API, то 4.

идея валидации данных в контроллере мне нравится еще меньше

Почему?

 

[grigori]

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

>Если у него есть внешнее API, то 4
если регистрация по open ID - то 5, если с базой работают напрямую - то 6, если данные парсятся из файлов, то 7, если делается бекап - то 8, если доступ по ftp - то 9
ты не путаешь работу с данными и интерфейс пользователя?
из твоего списка к UI относится только админка,
возможно, у тебя такие интересные задачи бывают, но я ни разу не создавал сайтов, чтобы регистрация пользователя была в нескольких местах.
В этом конкретном случае - да, стоит вынести валидацию каждого источника в отдельные модели, или создать группы правил валидации для разных ситуаций.

 

[korchasa]

да каша получается

Можно комбинировать:

ArticleController class
{
  ... 
  $validator = $article->getValidator()
  $validator->addRule('captcha', new EqualRule($captcha_value), 'Wrong CAPTCHA-code');
}

ты не путаешь работу с данными и интерфейс пользователя?

Нет. Консоль и API это тоже UI.

 

[grigori]

вот твой Validator по сути и есть модель, узкоспециализированная
if ($validator->validate()){
$user->setData($validator->getValidData());
}

 

[grigori]

>Консоль и API это тоже UI
консоль для консольного приложения - да, а тесты - это не UI, это "служебный вход", как ssh к веб-серверу,
а во внешнем API отсутствует U(ser), есть только программа-клиент
притянуть за уши можно, но надо ли ...
в общем случае я противник универсализации, но это выбор каждого

это просто точка зрения, неважно

 

[HraKK]

Что если делать так: просить у объекта User его валидатор

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

 

[varan]

А главное мы должны знать что у него он есть(ку-ку, инкапсуляция).

Какая разница с точки зрения инкапсуляции, ты будешь просить у него валидатор или ловить его исключениеНеВалидности?

 

[grigori]

>"просить у него валидатор"
по принципу бритвы Оккама для создания дополнительной сущности требуется причина - покажи ее

для поддержки множества источников достаточно множества наборов правил валидации;
какие причины генерировать специализированные модели для валидации, кроме вашего желания?

 

[Вурдалак]

$userData = getSomeVarsForCreate();
$User = new User( $userData );
try
{
    $User->save();
}

А уже внутри объекта зашиваете обработку может ли он с таким набором данных создать или нет.
Тут же, блин, все элементарно соедините принципы инкапсуляции и tell don't ask - получите профит.

Я не понял мысли. Ну, выдаст исключение, что пустой пароль недопустим и сохранять user'а не будет. А дальше что? Как привёл пример автор треда, админу может быть нужно сохранить юзера с пустым паролем или там email'ом, а простому пользователю это недопустимо.

 

[varan]

>"просить у него валидатор"
по принципу бритвы Оккама для создания дополнительной сущности требуется причина - покажи ее

Какая тут новая сущность? Новый метод getValidator и все. А сам класс Validator нужен в любом случае (универсальный для всех моделей, просто контейнер для правил валидации).

для поддержки множества источников достаточно множества наборов правил валидации;

Т.е. нужен новые метод addRules() или selectRulesSet() или типа того? Все равно как-то с моделью надо взаимодействовать, как ни крути.

 

[grigori]

одни и те же наборы данных в разных ситуациях могут быть допустимы или, наоборот, недопустимы.

у модели есть состояния
условия вызова меняют состояние, и модель валидирует данные соответственно состоянию

где ты видишь проблему?

 

[grigori]

>Какая тут новая сущность
Если мы просим валидатор - то получаем объект, т.е. сущность. Данные для валидации или заложены в нем (тогда он - модель), или ему нужна модель, с которой он будет работать.
Я пытаюсь понять цель создания этих новых сущностей, если модель с данными уже есть, и в нее же можно прописать правила валидации.

 

[Вурдалак]

grigori, какие состояния? Состояние «готовность быть вызванной админом» и обычное?

 

[grigori]

Вурдалак да хоть "состояние эрекции", называй как хочешь, но это софистика, давай по делу

 

[varan]

у модели есть состояния
условия вызова меняют состояние, и модель валидирует данные соответственно состоянию

где ты видишь проблему?

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

 

[Вурдалак]

Да я к чему это говорю. Если трудновато придумать адекватное название чему-то, то может быть ты делаешь что-то не так? Есть модель. Ей надо придумывать какие-то состояния. Сразу нужно задумываться о том где она должна использоваться... Неправильно как-то, IMHO.