Provide abstract middleware classes

[derrabus]

Q	A
Type	improvement
BC Break	no
Fixed issues	N/A

Summary

When writing a middleware, I have to start with a lot of delegating boilerplate code. As a DX improvement, I'd like to propose the introduction of abstract wrapper classes for driver, connection, statement and result. This allows a developer to only override the methods they want to hook into, resulting in smaller and focussed middleware classes.

I have already modified the portability and logging middlewares to use those abstract classes, so we can see the effect that those classes have.

Using those abstract classes of course remains optional. The contract is still defined by the interfaces, so a middleware can still be implemented without the abstract classes.

Although the new classes are already covered by the tests of the portability and logging middlewares, I intend to add dedicated tests for them, once we agree that we want to introduce those abstract classes.

[derrabus]

AppVeyor is drunk.

[morozov]

I'm all for it.

[stof]

why this array_slice magic instead of passing $length to the parent method ? the parent method won't do the same magic to pass extra parameters (or omit the length) to the wrapped statement anyway.

[mvorisek]

Shouldn't this property be protected or getter to be added?

Otherwise how are supposed the public/middleware methods to be overriden?

[derrabus]

No, it shouldn't.

You'll likely need to override the constructor anyway, so you can create your own private property for the wrapped driver if you really need it. Delegating a call to the wrapped driver can be done my calling the parent method, for example:

dbal/src/Logging/Driver.php

Lines 29 to 37 in 2485d0a

	public function connect(array $params)
	{
	$this->logger->info('Connecting with parameters {params}', ['params' => $this->maskPassword($params)]);
	return new Connection(
	parent::connect($params),
	$this->logger
	);
	}