Exceptions как и с чем

[fixxxer]

Где угодно на уровне http app, но не в model уж точно.

Ну и я не думаю, что для http-валидации вообще уместно выбрасывание исключений.

Касаемо валидации - в laravel, например, есть Form Requests: https://laravel.com/docs/5.4/validation#creating-form-requests

 

[WMix]

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

class UserService{
  function do(User $user){
    // ...
  }
  function createUser($name, $balba):User{
    // тут валидация и выкидываем исключение
    return new User($name, $balba);
  }
}

// middleware
function beforeMyAction(Request $r):User{
  // в этом месте вероятно придется исключение врапить
  // и чет мне совсем не нравится трайкэтчить
  try{
    return $service->createUser($r->name, $r->blabla);
  }
  catch(\Exception $e){
    throw BadRequestHttpException(...);
  }
}

// controller
function myAction(User $user){
   // тут всегда готовые обьекты
  return $service->do($user)
}

че думаешь?


https://silex.symfony.com/doc/2.0/usage.html#route-variable-converters

 

[fixxxer]

Я не понимаю, зачем это. Это аутентификация или что?

(Вот этот подход с анемичными моделями и классами типа FooService это, конечно, жесть еще похуже Active Record.)

 

[Вурдалак]

$service, do(), create(), myAction. Чо тут неясного-то?

 

[WMix]

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

function authenticateAction($nick, $pass){
  return $service->authenticate($nick, $pass);
}
function renameAction(User $user, $new_name){
  // только эта часть в сервисе уже
  $user->rename($new_name);
}

(прелюдия getById итд. всегда в middleware)
дальше только действия и визуализация результата. не понимаю почему "анемичный"?.

 

[fixxxer]

основная идея в том что в "действие" заходят только готовые обьекты

Для того чтобы что?

 

[Вурдалак]

@WMix, для переименования нужны $userId и $newName. Что ты там в своем «middleware» собрался валидировать?

 

[WMix]

@fixxxer, для того чтобы с этим работать, чтоб действия были короткими, чтоб сосредоточится на самом действии а не подготовке и проверке
@Вурдалак, $userId это клевая штука и в руте (POST /user/{userId}/rename) она вероятно так и называлась
в middleware мы из {userId} создали обьект User, мы проверили что он существует и разрешон (в моей группе где я админ к примеру)

 

[Вурдалак]

@fixxxer, для того чтобы с этим работать, чтоб действия были короткими, чтоб сосредоточится на самом действии а не подготовке и проверке

Для этого есть command handler'ы. Только по прежнему нужно передавать userId.

 

[WMix]

"command handler" это по сути тотже "action handler". в данном случае в action handler прописано что перед началом action запусти converter и создай из scalar-value object

 

[AnrDaemon]

try {
...
} catch (NotEnoughPermissions $e) {
    throw new HttpAccessDenied("message", 403, $e);
}

Не забывайте чейнить эксепшены…

 

[AnrDaemon]

только у модели нет клиентов

А я ни слова не сказал про модель. HTTP код является результатом работы запроса.

 

[Вурдалак]

"command handler" это по сути тотже "action handler". в данном случае в action handler прописано что перед началом action запусти converter и создай из scalar-value object

Нетранзакционно и привязано к HTTP (по сути action'ы-то — это часть HTTP-контроллеров).

 

[WMix]

Нетранзакционно

это нет, возможно несколько ограничено но,
вызов post это команда (изменение состояния), всегда 1 транзакция, всегда синхронно (session read/write).
вызов get это query, без транзакций, асинхронно (session read / write_close)
(по крайней мере это цель, есть исключения)

привязано к HTTP (по сути action'ы-то — это часть HTTP-контроллеров).

а как иначе?

 

[fixxxer]

Не забывайте чейнить эксепшены…

В данном конкретном случае, когда exception гарантированно будет обработан кодом вида return $response->status($e->getCode()), не вижу в этом смысла. Хотя сам обычно чейню тупо на автомате. Но на code review бы придираться не стал.

 

[WMix]

Не забывайте чейнить эксепшены…

это было в фанат'овской теме, пусть будет не суть

 

[Вурдалак]

это нет, возможно несколько ограничено но,
вызов post это команда (изменение состояния), всегда 1 транзакция, всегда синхронно (session read/write).
вызов get это query, без транзакций, асинхронно (session read / write_close)
(по крайней мере это цель, есть исключения)

Я не понял к чему этот набор утверждений. Где у тебя транзакция-то? Где ты пишешь SELECT ... FOR UPDATE?

а как иначе?

Эээ, command handler? Application, не привязанный ни к одному из внешних форматов.

 

[WMix]

Где ты пишешь SELECT ... FOR UPDATE?

class UserService{
    public function getUserById($id, $for_update=false){
        return $this->mapper->getById($id, $for_update);
    }
}
function before(Request $request){
  return $this->service->getUserById($request->attributes->get('id'), $request->isMethod(Request::METHOD_POST));
}

Эээ, command handler? Application, не привязанный ни к одному из внешних форматов.

я не очень понял, я подумаю

 

[Вурдалак]

class UserService{
    public function getUserById($id, $for_update=false){
        return $this->mapper->getById($id, $for_update);
    }
}
function before(Request $request){
  return $this->service->getUserById($request->attributes->get('id'), $request->isMethod(Request::METHOD_POST));
}

Что ты будешь делать, если в другом middleware есть какой-нибудь логгер, пишущий в базу, используя тот же connection? Что ты будешь делать, если у тебя есть событие, по которому синхронно выполняется другой обработчик, который тоже попадёт под действие транзакции (письмо отправится, а потом выяснится, что транзакцию нужно откатывать)? Что ты будешь делать, если соответствие «метод HTTP-API <-> бизнес-действие» перестанет быть взаимно однозначным (один вызов API -> несколько команд)?

Зачем вообще так завязываться на HTTP-контекст? Как ты собираешься переиспользовать то же бизнес-действие в CLI, в сценариях автотестов, в другом API (иметь одновременно несколько API разных форматов и версий в долгосрочных проектах — не редкость, ибо BC), в админке (админка может иметь свой API на другом хосте)? Я просто вызову $this->bus->handle(new RenameUser(42, 'Alice')), зная, что либо действие выполнится транзакционно, либо упадёт с ошибкой. А как вызывать твой «экшн», размазанный по куче классов? Делать sub/slave HTTP-request из CLI?

 

[WMix]

такие вопросы странные, как будто простую идею не понял, наоборот модель свободная, это http на моделе завязан. переиспользовать, вообще никаких проблем, мыло я отправлю через bus. те оно отправится если транзакция была завершена и демон не упал.

А как вызывать твой «экшн», размазанный по куче классов?

как угодно, так нравится?

$router['RenameUser']->handle(['id'=>42, 'name' => 'Alice']);

в админке

вобще не понимаю твою проблему

если ты о командах, то там ничего другого кроме вышеописаного.