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

Шаблон является базовым методом 'find [Type] s' в моих сервисных слоях, который абстрагирует создание запроса на выборку до одной точки в сервисе, но поддерживает возможность быстрого создания более простых в использовании прокси-методов (см. Пример PostServivce :: getPostById () метод ниже).

К сожалению, до сих пор я не смог достичь этих целей:

Уменьшить вероятность ошибок, вызванных повторной реализациейПредоставьте действительные / недействительные параметры параметров в IDE для автозаполненияСледуйте принципу СУХОЙ

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

class PostService
{
    /* ... */

    /**
     * Return a set of Posts
     *
     * @param Array $conditions Optional. An array of conditions in the format
     *                          array('condition1' => 'value', ...)
     * @param Array $options    Optional. An array of options 
     * @return Array An array of post objects or false if no matches for conditions
     */
    public function getPosts($conditions = array(), $options = array()) {
        $defaultOptions =  = array(
            'orderBy' => array('date_created' => 'DESC'),
            'paginate' => true,
            'hydrate' => 'array',
            'includeAuthor' => false,
            'includeCategories' => false,
        );

        $q = Doctrine_Query::create()
                        ->select('p.*')
                        ->from('Posts p');

        foreach($conditions as $condition => $value) {
            $not = false;
            $in = is_array($value);
            $null = is_null($value);                

            $operator = '=';
            // This part is particularly nasty :(
            // allow for conditions operator specification like
            //   'slug LIKE' => 'foo%',
            //   'comment_count >=' => 1,
            //   'approved NOT' => null,
            //   'id NOT IN' => array(...),
            if(false !== ($spacePos = strpos($conditions, ' '))) {
                $operator = substr($condition, $spacePost+1);
                $conditionStr = substr($condition, 0, $spacePos);

                /* ... snip validate matched condition, throw exception ... */
                if(substr($operatorStr, 0, 4) == 'NOT ') {
                  $not = true;
                  $operatorStr = substr($operatorStr, 4);
                }
                if($operatorStr == 'IN') {
                    $in = true;
                } elseif($operatorStr == 'NOT') {
                    $not = true;
                } else {
                    /* ... snip validate matched condition, throw exception ... */
                    $operator = $operatorStr;
                }

            }

            switch($condition) {
                // Joined table conditions
                case 'Author.role':
                case 'Author.id':
                    // hard set the inclusion of the author table
                    $options['includeAuthor'] = true;

                    // break; intentionally omitted
                /* ... snip other similar cases with omitted breaks ... */
                    // allow the condition to fall through to logic below

                // Model specific condition fields
                case 'id': 
                case 'title':
                case 'body':
                /* ... snip various valid conditions ... */
                    if($in) {
                        if($not) {
                            $q->andWhereNotIn("p.{$condition}", $value);
                        } else {
                            $q->andWhereIn("p.{$condition}", $value);
                        }
                    } elseif ($null) {
                        $q->andWhere("p.{$condition} IS " 
                                     . ($not ? 'NOT ' : '') 
                                     . " NULL");
                    } else {
                        $q->andWhere(
                            "p.{condition} {$operator} ?" 
                                . ($operator == 'BETWEEN' ? ' AND ?' : ''),
                            $value
                        );
                    }
                    break;
                default:
                    throw new Exception("Unknown condition '$condition'");
            }
        }

        // Process options

        // init some later processing flags
        $includeAuthor = $includeCategories = $paginate = false;
        foreach(array_merge_recursivce($detaultOptions, $options) as $option => $value) {
            switch($option) {
                case 'includeAuthor':
                case 'includeCategories':
                case 'paginate':
                /* ... snip ... */
                    $$option = (bool)$value;
                    break;
                case 'limit':
                case 'offset':
                case 'orderBy':
                    $q->$option($value);
                    break;
                case 'hydrate':
                    /* ... set a doctrine hydration mode into $hydration */ 
                    break;
                default:
                    throw new Exception("Invalid option '$option'");
            }
        }

        // Manage some flags...
        if($includeAuthor) {
            $q->leftJoin('p.Authors a')
              ->addSelect('a.*');
        } 

        if($paginate) {
            /* ... wrap query in some custom Doctrine Zend_Paginator class ... */
            return $paginator;
        }

        return $q->execute(array(), $hydration);
    }

    /* ... snip ... */
}

Phewf

Преимущества этой базовой функции:

это позволяет мне быстро поддерживать новые условия и параметры по мере развития схемыэто позволяет мне быстро реализовать глобальные условия в запросе (например, добавив опцию 'excludeDisabled' со значением по умолчанию true и отфильтровав все модели disabled = 0, если только вызывающая сторона явно не скажет иначе).это позволяет мне быстро создавать новые, более простые в использовании методы, которые прокси вызывает обратно к методу findPosts. Например:

class PostService
{
    /* ... snip ... */

    // A proxy to getPosts that limits results to 1 and returns just that element
    public function getPost($conditions = array(), $options()) {
        $conditions['id'] = $id;
        $options['limit'] = 1;
        $options['paginate'] = false;
        $results = $this->getPosts($conditions, $options);
        if(!empty($results) AND is_array($results)) {
            return array_shift($results);
        }
        return false;
    }

    /* ... docblock ...*/       
    public function getPostById(int $id, $conditions = array(), $options()) {
        $conditions['id'] = $id;
        return $this->getPost($conditions, $options);
    }

    /* ... docblock ...*/
    public function getPostsByAuthorId(int $id, $conditions = array(), $options()) {
        $conditions['Author.id'] = $id;
        return $this->getPosts($conditions, $options);
    }

    /* ... snip ... */
}

ГЛАВНЫЙ Недостатками этого подхода являются:

Один и тот же монолитный метод 'find [Model] s' создается в каждой службе, обращающейся к модели, в основном меняются только конструкция переключателя условий и имена базовых таблиц.Нет простого способа выполнить операции И / ИЛИ. Все условия явно ANDed.Представляет много возможностей для опечатокВводит множество возможностей для разрывов в API, основанном на соглашениях (например, для более поздней службы может потребоваться реализация другого соглашения о синтаксисе для указания опции orderBy, которая становится утомительной для обратного переноса на все предыдущие службы).Нарушает СУХИЕ принципы.Допустимые условия и параметры скрыты в анализаторах автозаполнения IDE, а параметры и параметры параметров требуют длинного объяснения блока документов для отслеживания разрешенных параметров.

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

Идея, над которой я работал, была чем-то вроде следующего (текущий проект будет Doctrine2 fyi, так что небольшие изменения там) ...

namespace Foo\Service;

use Foo\Service\PostService\FindConditions; // extends a common \Foo\FindConditions abstract
use Foo\FindConditions\Mapper\Dql as DqlConditionsMapper;

use Foo\Service\PostService\FindOptions; // extends a common \Foo\FindOptions abstract
use Foo\FindOptions\Mapper\Dql as DqlOptionsMapper;

use \Doctrine\ORM\QueryBuilder;

class PostService
{
    /* ... snip ... */
    public function findUsers(FindConditions $conditions = null, FindOptions $options = null) {

        /* ... snip instantiate $q as a Doctrine\ORM\QueryBuilder ... */

        // Verbose
        $mapper = new DqlConditionsMapper();
        $q = $mapper
                ->setQuery($q)
                ->setConditions($conditions)
                ->map();

        // Concise
        $optionsMapper = new DqlOptionsMapper($q);        
        $q = $optionsMapper->map($options);


        if($conditionsMapper->hasUnmappedConditions()) {
            /* .. very specific condition handling ... */
        }
        if($optionsMapper->hasUnmappedConditions()) {
            /* .. very specific condition handling ... */
        }

        if($conditions->paginate) {
            return new Some_Doctrine2_Zend_Paginator_Adapter($q);
        } else {
            return $q->execute();
        }
    }

    /* ... snip ... */
}

И, наконец, пример класса Foo \ Service \ PostService \ FindConditions:

namespace Foo\Service\PostService;

use Foo\Options\FindConditions as FindConditionsAbstract;

class FindConditions extends FindConditionsAbstract {

    protected $_allowedOptions = array(
        'user_id',
        'status',
        'Credentials.credential',
    );

    /* ... snip explicit get/sets for allowed options to provide ide autocompletion help */
}

Foo \ Options \ FindConditions и Foo \ Options \ FindOptions действительно очень похожи, поэтому, по крайней мере, на данный момент они оба расширяют общий родительский класс Foo \ Options. Этот родительский класс обрабатывает инициализацию разрешенных переменных и значений по умолчанию, осуществляет доступ к заданным параметрам, ограничивает доступ только определенными параметрами и предоставляет интерфейс итератора для DqlOptionsMapper для циклического просмотра параметров.

К сожалению, после взлома этого в течение нескольких дней, я чувствую разочарование по поводу сложности этой системы. Как и раньше, в этой группе до сих пор нет поддержки групп условий и условий ИЛИ, и возможность указать альтернативные операторы сравнения условий была полным затруднением при создании класса Foo \ Options \ FindConditions \ Comparison, обернутого вокруг значения при указании FindConditions. стоимость ($conditions->setCondition('Foo', new Comparison('NOT LIKE', 'bar'));).

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

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

Итак, Stack Overflowers: - Есть ли лучший способ, который обеспечивает преимущества, которые я определил, без учета недостатков?