我有两个与 Phalcon 中的模型相关的问题,我正在努力寻找答案:
- 如何访问模型中的依赖注入器?
- 创建一个未绑定到数据库表的模型是否合理?如果不是,那么我应该把不需要存储的逻辑放在哪里(一些函数可以与 API 一起使用)?
我有两个与 Phalcon 中的模型相关的问题,我正在努力寻找答案:
您可以使用该函数Di
从代码中的任何位置访问getDefault()
$di = \Phalcon\DI\FactoryDefault::getDefault();
您可以扩展 Phalcon 模型以公开某些功能并使用该功能扩展您的模型。例如,考虑以下提供更多功能的模型(您始终可以根据需要对其进行扩展。在下面的示例中,我将展示如何使用构建器来构建查询以及可用于获取模式的函数对于特定型号。
class MyModel extends \Phalcon\Mvc\Model
{
protected static function di()
{
return \Phalcon\DI\FactoryDefault::getDefault();
}
public static function fetchSchema()
{
return "schema generators";
}
public static function fetchById($id)
{
$results = null;
try {
$builder = self::getBuilder();
$field = 'id';
$bind[$field] = $id;
$builder->where("{$field} = :{$field}:");
$query = $builder->getQuery();
// One record is needed here so set the unique row
$query->setUniqueRow(true);
// Execute!
$results[] = $query->execute($bind);
} catch (\Exception $e) {
$results = self::exceptionToArray($e);
}
return $results;
}
protected static function getBuilder()
{
$di = self::di();
$manager = $di['modelsManager'];
$builder = $manager->createBuilder();
$builder->from(get_called_class());
return $builder;
}
protected static function execute($builder, $bind, $unique = false)
{
$query = $builder->getQuery();
// One record is needed here so set the unique row
$query->setUniqueRow($unique);
// Execute!
$results = $query->execute($bind);
if (!$results || count($results) == 0) {
$results = array();
}
return $results;
}
protected static function exceptionToArray($exception)
{
$results['error'] = array(
'code' => $exception->getCode(),
'file' => $exception->getFile(),
'line' => $exception->getLine(),
'message' => $exception->getMessage(),
'trace' => $exception->getTrace(),
'trace_as_string' => $exception->getTraceAsString()
);
return $results;
}
}
我不知道这个特定的框架,但在应用程序代码中访问依赖注入容器绝对是个坏主意。依赖注入容器应该只存在于应用程序的顶层。它应该创建模型并将其完全构建的依赖项传递给它所需的一切。
1)它将您的应用程序逻辑与框架紧密耦合,这不好,因为您的代码不可移植
2)它使您的应用程序代码可以访问所有可能的依赖项。这意味着它没有明确的 API。代码实际上有什么依赖关系?如果不查看代码并查看它从 DI 容器中获取的内容,您将无法回答这个问题。见: http: //misko.hevery.com/code-reviewers-guide/flaw-digging-into-collaborators/