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

[Koc]

Контроллеры толстеют (превед, ТТУК), валидация в них дублируется и в то же время выносить ее в модели не совсем корректно, так как бывают разные юз-кейсы: админ может создать юзера с пустым паролем а юзер не может, к примеру - такие вещи явно не модель должна разруливать.

Грубо говоря, мне нужно комплексное решение для:
1) гибкой валидации данных
2) binding данных из Request'а на Entities (Doctrine2, но не всегда)

Я кажется нашел, что мне подойдет - Symfony\Component\Form. В качестве бонуса получаем
3) binding данных из Request'а и Entities на формы.


В правильном ли направлении я двигаюсь?

 

[cDLEON]

Почему не модель? По-моему ей в самый раз этим заниматься. Всё таки ей данные суют
Можно, например, для админа (в этих спорных юз-кейсах) использовать отнаследованную модель с своей валидацией таких полей.

Можно, конечно, разруливать и на уровне формы - но тогда привет шаблонный гемор

 

[Koc]

Почему не модель? По-моему ей в самый раз этим заниматься. Всё таки ей данные суют

я наверно не так выразился. Я имел в виду, что это не задача сущности (легковесный класс с геттерами/сеттерами). Модель: сущность + набор правил для ее валидации + источник данных.

Можно, конечно, разруливать и на уровне формы - но тогда привет шаблонный гемор

смотри как изящно это предлагают решить http://www.slideshare.net/bschussek/the-new-form-framework (слайд 43 и за ним)

 

[cDLEON]

Я симфониевской красоты не понимаю Как можно было додуматься совать атрибуты в phpDoc для меня загадка
Поэтому, я с тобой в этом вопросе не собеседник =\

 

[itprog]

Как можно было додуматься совать атрибуты в phpDoc для меня загадка

почему бы и нет? очень даже удобно, все на виду, по желанию скрывается фолдингом. Единственная проблема автокомплит в IDE, но это дело поправимо

 

[Koc]

насколько я понимаю, это не столько симфониевская сколько явовская красота

Как можно было додуматься совать атрибуты в phpDoc для меня загадка

ну валидацию я тоже не делал бы через аннотации. Ну так там есть поддержка phpStaticMethod/yaml/xml

 

[Духовность™]

ИМХО валидация - дело контроллера, а не слоя. Задача слоя лишь сохранить данные. У меня тоже может показаться, что контроллеры ТТУК - http://pastebin.com/z4D6pghJ но по факту ТТУК там начинается лишь со строки 112 и заканчивается строкой 123.

 

[cDLEON]

Одна лишь проблема. ПХП != Ява
itprog
Есть ещё одна проблема - огроомный оверхед от постоянного парсинга каждого такого файла

 

[itprog]

cDLEON
а, так не надо ничего парсить, все уже есть в PHP: ReflectionProperty::getDocComment()

 

[cDLEON]

itprog
Угу. Значит сам коммент парсить не нужно да ? )

 

[varan]

вроде бы кто-то утверждал, что поддержка аннотаций появится в php 5.4

 

[HraKK]

Service Layor + Exception вас спасут.

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

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

 

[Koc]

itprog
Угу. Значит сам коммент парсить не нужно да ? )

все это кешируется, в том же APC

Service Layor + Exception вас спасут.

подробнее плизз. Что это за валидация такая с кидком эксепшена? антиюзабилити какое-то

 

[Koc]

HraKK
у меня не активрекорд

 

[HraKK]

Koc
Причем тут актив рекорд? User - это не AR. Это ОБЪЕКТ! Это Ваш Service Layer. Внутри себя он может делать что хочет. Не нравиться AR сделай

save( $someDataUser )

Неудивительно что вас мучают ТТУКи.

Валидация простая.

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

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

 

[Koc]

записал как один из вариантов

а вот еще порекомендовали глянуть
http://yugeon-dev.blogspot.com/2010/09/zend-framework.html
http://yugeon-dev.blogspot.com/2010/09/blog-post.html
http://yugeon-dev.blogspot.com/2010/10/blog-post.html

 

[HraKK]

если прочитаешь первую ссылку или МФ то получишь мое решение)

 

[varan]

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

Я вот что думаю, возможно туплю

Имхо вышеупомянутый объект не может валидировать капчу и повторный ввод пароля, потому что он например может создаваться вообще не из формы, а скриптом из csv- файла.
Кроме того, форма может состоять из нескольких частей: подтверждение оформления заказа и тут же регистрация, т.е. совершенно разные объекты, приделанные к одной форме.
Получается, должно быть два набора правил для валидации - правила валидации объекта домена, и правила валидации, так сказать, конкретной формы, или части формы. И при этом сообщения об ошибках надо выдавать все сразу. Эксепшены при таком раскладе будут имхо неудобны.

Что если делать так: просить у объекта User его валидатор, т.е. объект, содержащий набор правил для валидации пользователя как объекта бизнес-логики, потом брать откуда-нибудь еще валидатор части формы регистрации (капча, повтор пароля, галочка соглашения с бредовыми условиями), слеплять их вместе в один totalValidator и потом

if ($totalValidator->validate())
   //все хорошо, создаем пользователя, редиректим на welcome page
else
   //все плохо, редиректим на страницу с ошибкой

при этом не будет нарушен принцип tell don't ask и контроллер выполняет свою функцию клея

 

[whirlwind]

Не надо в конструктор модели пихать данные. Создайте фабричный/[назовите как вам больше нравится] метод в коллекции/маппере класса модели. А еще проще - fromArray, а для конвертации в стандартный вид/модель используйте Adapter. Хотите, с подпиской на invalidate.

 

[Koc]

varan,

смотри как изящно это предлагают решить http://www.slideshare.net/bschussek/the-new-form-framework (слайд 43 и за ним)

whirlwind
В репозитории логично будет его (фабричный метод) сделать?