Take IDbConnection and IDbTransaction instead of concrete types

[madelson]

Take IDbConnection and IDbTransaction instead of concrete types

[madelson]

Thank you for your interest in the library!

The reason that I went with the abstract classes over the interfaces is that my impression was that the abstract classes were intended to replace the interfaces as the main abstraction point going forward. The reason for this is that abstract classes can be added to over time, whereas MSFT cannot add new methods to interfaces because it breaks backwards compatibility. There's a big discussion on this topic here: https://github.com/dotnet/corefx/issues/3480, with several posts covering the history of these APIs.

In particular, this was relevant for SqlDistributedLock when async/await came out: methods like OpenAsync() and ExecuteReaderAsync() were added to DbConnection/DbCommand, but could not be added to IDbConnection/IDbCommand.

That said, if it were important I suppose I could write code like the following:

var dbConnection = this.idbConnection as DbConnection;
if (dbConnection != null) { await dbConnection.OpenAsync(); }
else { this.idbConnection.Open(); }

I'm curious, are there particular scenarios where you find you can't write your tests against DbConnection? Or is it more that you have an existing codebase that uses IDbConnection heavily?

[cable729]

Thanks @madelson for the response, and thanks for making this library. We're using NHibernate 3, which exposes an ISession, which in turn exposes an IDbConnection, but not a DbConnection (maybe this is changed in 4.x, I'm not sure). I wanted to pass in that connection or the ITransaction it also exposed, but it wasn't actually creating locks.

I got around the issue by passing a connection string.

[madelson]

@cable729 I've added support for this in the new version 1.2 release (see https://github.com/madelson/DistributedLock/blob/master/DistributedLock/Sql/SqlDistributedLock.cs#L74). Let me know if you have any issues!