4

または、そのためのフレームワーク。

例として Zend Framework 2 を使用すると、次のテーブル クラスがあります。

<?php

namespace Contact\Model;

use Zend\Db\TableGateway\TableGateway;
use Zend\Db\TableGateway\AbstractTableGateway;
use Zend\Log\Logger;

class UserContactsTable extends AbstractTableGateway
{
    protected $tableGateway;

    /**
     *
     * @var \Zend\Log\Logger Instance
     */
    protected $logger;

    public function __construct(TableGateway $tableGateway, Logger $logger )
    {
        $this->tableGateway = $tableGateway;
        $this->logger       = $logger;
    }

    /**
     * Save a contact
     * 
     * @param \Sms\Model\UserContact $userContact
     */
    public function saveUserContact(UserContact $userContact)
    {
        $data = array(
            'user_id'       => $userContact->user_id,
            'contact_id'    => $userContact->contact_id
        );

        try {
            $this->tableGateway->insert($data);
        } catch (\Exception $e) {
                    //log
            $this->logger->crit($omeErrMsg);

        }
    }
}
?>

ここにログインする必要がありますか？ロガーをテーブル クラスに関連付ける必要がありますか? 挿入が失敗した場合、saveUserContact 関数が例外をスローし、コントローラーでキャッチしてそこにログを記録する必要がありますか?

ベストプラクティスは何ですか?

私の最初のアイデアは、ロガーによってテーブル クラスで使用される挿入や更新の失敗など、いくつかの一定のエラー メッセージを含むクラスを作成することでしたが、ここで正しいプロセスが何であるかはわかりません。

これは実際には PHP や Zend Framework 2 に限定されたものではありませんが、たまたま私が使用している言語にも当てはまります。

4

2 に答える 2

6

私は、システムの個々のコンポーネントは可能な限り切り離すべきだと考えています。したがって、この例では、saveUserContactたまたま失敗した場合、これは予期された動作ではないため、例外がスローされる可能性があります。このクラスは、エラー ログなど、「チェーンのさらに上」で何が起こるかを知る必要はありません。

あなたが言及したように、例外をスローしてコントローラー (またはおそらく他の形式のリスナー) でキャッチし、ログを処理する方がよいでしょう。

このようなアプローチの利点は、テストする UserContactsTable (モック) オブジェクトを構築するときにスタブするオブジェクトが少なくなるため、システムのテストがはるかに簡単になることです。

于 2013-01-11T17:52:48.560 に答える
2

一般的に、エラーが発生した場所でエラーをログに記録する必要があるように感じますが(予想される場合を除き、ノイズが多い場合を除きます)、呼び出し元が無視/再試行/失敗するかどうかを決定できるように、例外をスタック (またはラッパー例外) に伝達する必要があります。 (そして、よりビジネス ロジックに関連する独自のメッセージをログに記録します)。

于 2013-01-11T17:40:20.163 に答える