Where to log database errors in MVC Architecture

Question

Or any framework for that matter.

Using Zend Framework 2 as an example, I have the following table class:

<?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);

        }
    }
}
?>

Should I be logging here? Should I tie my logger in to the table class? Should I let the saveUserContact function throw an exception if insert fails and catch in the controller and log there?

What are the best practises?

My original idea was to create a class with some constant error messages, such as insert and update failures to be used in the table class by the logger, but I'm not sure what is the correct process here.

This is not really limited to PHP or Zend Framework 2 but just so happens to be the language I am using.

RobMasters · Accepted Answer · 2013-01-11 17:52:48Z

6

I'd be of the opinion that individual components of a system should be as decoupled as possible. So in this example, if saveUserContact happens to fail then it should probably result in an exception being thrown because this isn't the expected behaviour. This class doesn't need to know about what will happen 'further up the chain', such as error logging.

As you mentioned, it would be better to throw the exception and catch it in your controller (or some other form of listener perhaps), which would then handle the logging.

The benefit of such an approach is that your system will be much easier to test because you'll have less objects to stub when constructing your UserContactsTable (mock) object to test.

answered Jan 11, 2013 at 17:52

RobMasters

4,1462 gold badges29 silver badges34 bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

Aydin Hassan Over a year ago

I feared this would be the answer after passing my logger object to all my tables and logging there instead of in the controller. Damn. Thanks for clarifying.

yechabbi Over a year ago

Definitely agree with @RobMasters. If you use a classic multi layered architecture : Web MVC - Service Layer - Persistence layer, then your db persistence layer should be decoupled from your logging logic. As suggested by RobMasters, I would catch the exceptions at the controller level, then delegate the handling to a logging service that depending on the type of the exception, would log the necessary information according to the necessary logic (email, write to file, to another dedicated database ...)

Rob Starling · Accepted Answer · 2013-01-11 17:40:20Z

2

Generally, i feel like you should log failures where they happen (unless they're expected, in which case that's noisy) but propagate an exception up the stack (or a wrapper exception) so the caller can decide whether to ignore/retry/fail (and log its own, more business-logic-relevant message).

answered Jan 11, 2013 at 17:40

Rob Starling

3,9083 gold badges25 silver badges40 bronze badges

Collectives™ on Stack Overflow

Where to log database errors in MVC Architecture

2 Answers 2

2 Comments

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Related