为什么让$ output输出Symfony命令类属性是不好的

时间:2017-10-26 16:36:38

标签: php symfony console command

我会写一些命令来检查我的应用程序是否一切正常。

因为这些命令将由cronjob执行,我想将输出格式化为可在日志文件中利用。

为了在命令的任何地方显示错误消息(不在每个方法调用中都传递$ output)我将它设为类属性,它非常方便但看起来很糟糕,我知道它很糟糕但我不知道为什么。这是一个例子:

<?php
namespace CheckingBundle\Command;

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

/**
 * Class CheckingCommand
 *
 */
class CheckingCommand extends Command
{
    /**
     * @var OutputInterface $output
     */
    private $output;

    protected function configure()
    {
        $this->setName('check:all');
    }

    protected function initialize(InputInterface $input, OutputInterface $output)
    {
        $this->output = $output;
    }

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $this->checkSqlConnection();
    }

    protected function checkSqlConnection()
    {
        $myConnexion = null; //Try to connect to database
        if (null === $myConnexion) {
            $this->sendError('Cannot connect to MySQL database');
        }
    }

    /**
     * @param string $errorMessage
     */
    protected function sendError($errorMessage)
    {
        $this->output->write(sprintf('%s <error>%s</error>', date('Y-m-d H:i:s'), $errorMessage));
    }
}

有人可以解释为什么它是坏的(如果是的话)?将它传递到任何地方都不会更好:

 $this->checkSqlConnection($output);

 protected function checkSqlConnection(Output $output)
   {
       $myConnexion = null; //Try to connect to database
       if (null === $myConnexion) {
           $output->write('Cannot connect to MySQL database');
       }
   }

我是否应该使用try / catch在命令中使用异常并在catch中使用我的sendError方法?这可能是处理错误的好方法,但如果我想在方法中显示其他信息呢?

1 个答案:

答案 0 :(得分:1)

我想指出两件事, 1)checkSqlConnection不应该在命令类中,它应该在一个单独的类(可能是一个服务)中,你需要将这个类作为服务公开并在命令类中使用它,你的业务逻辑不应该在命令类

2)正如您所提到的,传递$input$output个实例的代码并不好,但这并不好,因为您的服务类与输入紧密耦合/输出类

解决方案?使用Monolog而不是outputInterface, 从symfony 2.4开始,控制台组件与Monolog集成,它具有控制台处理程序,用于监听控制台事件并根据日志级别和控制台详细程度将日志消息写入控制台输出

Read more