Background:
I'm in the process of integrating Dapper into an existing application that has a legacy DAL based off of the DAAB of years gone by. This is a fairly large code base so it has to be done incrementally. My first attempt is taking a method that calls a reader and populates a collection of objects.
What I'm noticing is that the query extension method seems to be calling the IDbCommand.ExecuteReader and the legacy DAL implementation is being invoked instead of the Dapper version.
So my question is this "Is there a way to explicitly force Dapper to use it's implementation of IDbCommand.ExecuteReader and not the legacy version?"
Setup Connection: The open connection is coming from the existing framework and it completely wraps the IDbConnection interface plus some. There is a lot of security around getting this connection, and other additions that seem to muddy the waters.
private static XyDbConnection GetConnection()
{
return XyDbConnection.GetConnection(ExternalFieldDataConstants.ConnectionName.SecureRepositoryConnection);
}
Callsite: Nothing terrible going on here just setup of Dapper in a typical scenario
private void GetFieldMappingTableDapper()
{
const string commandText = @"
SELECT
OD.ObjectDefId,
OD.Name,
FM.LOBField,
FM.XPath,
FM.XPathDataType,
FM.legacyOnly,
BA.NAME BusinessAreaName
FROM [FieldMapping] FM
JOIN [ObjectDef] OD
ON OD.ObjectDefId = FM.ObjectDefId
JOIN [BusinessArea] BA
ON BA.BusinessAreaId = OD.BusinessAreaId";
using (var conn = GetConnection())
{
_mappingsCache = conn.Query<FieldMappingEx>(commandText).ToList();
}
}
Pictures are worth a thousand words.
Setting up the call to Dapper:
Now when I step (F11) into the call I get:
And now the most interesting part is the invocation of the legacy command object from Dapper. (it seems)
I've used Dapper for years, even with Oracle :) and this is the first time I've ever had a hickup, period.
Thank you, Stephen
Yes, dapper calls the CreateCommand
method on the connection. It has to. It doesn't know anything about what type of connection you are using. That is literally the only way you should (as a provider-agnostic library) create a command. Is there a different way you expected it to create an ado.net command?