Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Take IDbConnection and IDbTransaction instead of concrete types #3

Closed
cable729 opened this issue Jan 6, 2017 · 3 comments
Closed

Comments

@cable729
Copy link

cable729 commented Jan 6, 2017

The SqlDistributedLock constructor should take interfaces instead of concrete classes. This allows it and classes that create it to be unit tested more easily.

@madelson
Copy link
Owner

madelson commented Jan 9, 2017

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
Copy link
Author

cable729 commented Jan 9, 2017

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
Copy link
Owner

madelson commented Feb 4, 2017

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants