多年来，我一直在一遍又一遍地（随着进化）重新实现相同的代码，却没有找到某种干净、有效的方法，将其抽象出来。
该模式是我的服务层中的基本“find[Type]s”方法，它将选择查询创建抽象到服务中的单个点，但支持快速创建更易于使用的代理方法的能力（参见示例 PostServivce::getPostById () 方法方式如下）。
不幸的是，到目前为止，我一直无法满足这些目标：
- 减少由不同的重新实现引入的错误的可能性
- 向 IDE 公开有效/无效参数选项以进行自动完成
- 遵循 DRY 原则
我最近的实现通常类似于以下示例。该方法采用一组条件和一组选项，并从中创建并执行一个 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 ... */
}
呼
这个基函数的好处是：
- 它使我能够随着架构的发展快速支持新的条件和选项
- 它允许我在查询中快速实现全局条件（例如，添加一个默认为 true 的 'excludeDisabled' 选项，并过滤所有 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”方法，大部分情况下只有条件切换构造和基表名称发生变化。
- 没有简单的方法来执行 AND/OR 条件操作。所有条件都明确地与。
- 引入了许多拼写错误的机会
- 在基于约定的 API 中引入了许多中断的机会（例如，以后的服务可能需要实现不同的语法约定来指定 orderBy 选项，这对于向后移植到所有以前的服务变得乏味）。
- 违反 DRY 原则。
- 有效条件和选项对 IDE 自动完成解析器隐藏，选项和条件参数需要冗长的文档块解释来跟踪允许的选项。
在过去的几天里，我试图为这个问题开发一个更面向对象的解决方案，但我觉得我正在开发一个过于复杂的解决方案，这个解决方案将过于僵化和限制使用。
我正在努力的想法类似于以下内容（当前项目将是 Doctrine2 仅供参考，所以略有改变）......
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 提供一个迭代器接口来循环选项。
不幸的是，在研究了几天之后，我对这个系统的复杂性感到沮丧。照原样，这仍然不支持条件组和 OR 条件，并且指定备用条件比较运算符的能力已经完全陷入了创建 Foo\Options\FindConditions\Comparison 类在指定 FindConditions 时环绕一个值的泥潭值 ( $conditions->setCondition('Foo', new Comparison('NOT LIKE', 'bar'));)。
如果存在的话，我宁愿使用其他人的解决方案，但我还没有遇到任何可以满足我要求的东西。
我想超越这个过程，回到实际构建我正在从事的项目，但我什至看不到结束的迹象。
所以，Stack Overflowers： - 有没有更好的方法可以提供我已经确定的好处而不包括缺点？