Фасад над API запросами. Как собрать объекты, их информацию и упаковать в один запрос?

Question

[Roquie]

Имеется API обертка над запросами. Они построены так, что в одном http запросе можно внутри послать еще пачку на выборку, изменение, создание данных и т.п.

Хотел сделать статический фасад, на подобие:

Users::find($user_id);
Users::create(['name' => 'foobar']);

$s = new Service($id);
$s->field = 'FooBar';
$s->update();

Reference::findByType(Type::ORGS);

Где каждая строка по-сути это запрос на удаленный сервер. Интересует как в этих объектах собрать общие параметры запроса и послать одим в последнем методе?
Какие паттерны под это дело существуют? Фабрика и наблюдатель, мне кажется не подходят. Да и городить монструозное ООП не хочется, а сделать легкий фасад, как в Laravel например.

Answer 1

[Антон Шаманов]

Зачем все мешать в кучу? Подобные скрипты обычно строятся на REST архитектуре.

Comments

[Roquie]

Строятся, но оно уже было построено до меня, людьми про REST не слышавших. Но в API есть интересная особенность послать пачку запросов одним - тогдо оно выполнится быстрее нежели ждать 5 обращений к серверу. У вас предложения конкретно по вопросу есть?

[Антон Шаманов]

Roquie: все классы генерирующие подзапросы наследуют базовый интерфейс\абстрактный класс в котором задан метод возвращающий результат в виде объекта наследующего интерфейс результатов, объекты - подзапросы передаются в объект - коллектор который принимает только наследников интерфейса-результата, после того как все подзапросы переданы преобразуем их в строку запроса и передаем

[Roquie]

Антон Шаманов: Спасибо, описание немного сбивает с толку при попытке имитировать пример. Можете показать его в реализации?

[Антон Шаманов]

Roquie: вариант попроще

interface Query 
{
    /**
     * @return string
     */
    public function result();
}

class QueryInsert implements Query
{
    public function result()
    {
        return 'QueryInsertString';
    }
}

class QueryDelete implements Query
{
    public function result()
    {
        return 'QueryDeleteString';
    }
}

class QueryCollection
{
    protected $queries = [];

    /**
     * @return void
     */
    public function setQuery(Query $query)
    {
        $this->queries[] = $query;
    }

    /**
     * @return string
     */
    public function render()
    {
        $str = '';
        foreach ($this->queries as $query) {
            $str .= $query->result();
        }
        return $str;
    }
}

[Roquie]

Антон Шаманов: хм, так и предполагал задавая вопрос, разве что в коллектор передавать сразу все объекты $obj->collect($query1, $query2, $query3);... но, без этого никак? а то запись с возвращением объектов подзапросов и потом передача их в коллектор будет не очень компактна =\

[Roquie]

Как-то вот так....

$query1 = Users::find($user_id);
$query2 = Users::create(['name' => 'foobar']);

$s = new Service($id);
$s->field = 'FooBar';
$query3 = $s->update();

$query4 = Reference::findByType(Type::ORGS);

$obj = new Collection($query1, $query2, $query3, $query4);
$obj->send();

[Антон Шаманов]

Roquie: код должен быть читабелен\понятен\задокументирован, какой практический смысл в излишней скомканности кода?

[Антон Шаманов]

Roquie: в твоем варианте не гарантируется что запросы наследуют общий интерфейс

[Антон Шаманов]

Roquie: в качестве родителя для класса коллектора можно использовать php.net/manual/en/class.splobjectstorage.php , статья о коллекциях habrahabr.ru/post/144182

[Roquie]

Антон Шаманов: ок, щас гляну. Ответ на вопрос: это просто эстетика, ну я поэтому и "слямзал" описание фасада для работы с API у Laravel Eloquent )) В общем, к черту эстетику. Все равно помимо этого тут будет кеширование и логгирование.

[Roquie]

Антон Шаманов:
"в твоем варианте не гарантируется что запросы наследуют общий интерфейс"
кстати, гарантируется

public function set(QueryInterface $query)
    {
        $args = func_get_args();

        foreach ($args as $k => $argument)
            if ($query instanceof QueryInterface && ! $this->contains($argument))
                $this->attach($argument);

        return $this;
    }

;)

[Антон Шаманов]

Roquie: подправил, да через жопу

[Roquie]

Антон Шаманов: объясните, почему? Ведь объекты задавать одним методом удобнее, нежели вызывать его каждый раз.

[Антон Шаманов]

Roquie: set(QueryInterface $query)

[Антон Шаманов]

Roquie: это как минимум, а после того как исправишь эту ошибку стоит задуматься а если в метод выполнят без значений?

[Roquie]

Антон Шаманов: лол, писал для примера, если вы об этом:

public function set()
    {
        $args = func_get_args();

        foreach ($args as $k => $argument)
            if ($argument instanceof QueryInterface && !$this->contains($argument))
                $this->attach($argument);
            else
                throw new \LogicException('bag arg');

        return $this;
    }

[Roquie]

не LogicException, а InvalidArgException...

[Roquie]

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

[Антон Шаманов]

Roquie: сначала тесты напиши, а потом выё..ся (с) программистская пословица

[Roquie]

Антон Шаманов: :D верно. Но, какой прок от этой ошибки, если при прямом вызове render() результат будет тотже, что в set()? Делать одну и туже проверку в двух методах на кол-во объектов в хранилище?