Interception in Entity Framework Core
Right now, Entity Framework Core still does not have all of the features provided by pre-Core versions, I even wrote a post about this. One of this features is the ability to intercept queries, something that was provided by the IDbCommandInterceptor, IDbCommandTreeInterceptor interfaces.
What we have in EF Core 2.0 is interception at the SQL level, and we can only get to this in a rather convoluted way, through the DiagnosticSource mechanism (yes, I do intend to write about it!). So, let’s create a class with three methods, like this:
public class CommandListener
{
[DiagnosticName("Microsoft.EntityFrameworkCore.Database.Command.CommandExecuting")]
public void OnCommandExecuting(DbCommand command, DbCommandMethod executeMethod, Guid commandId, Guid connectionId, bool async, DateTimeOffset startTime)
{
}
[DiagnosticName("Microsoft.EntityFrameworkCore.Database.Command.CommandExecuted")]
public void OnCommandExecuted(object result, bool async)
{
}
[DiagnosticName("Microsoft.EntityFrameworkCore.Database.Command.CommandError")] public void OnCommandError(Exception exception, bool async) { }
}
You will need the Microsoft.Extensions.DiagnosticAdapter NuGet package to compile this.
We hook these methods to EF Core like this:
var listener = ctx.GetService<DiagnosticSource>();
(listener as DiagnosticListener).SubscribeWithAdapter(new CommandListener());
Here, ctx is a DbContext, and we are accessing it’s registered DiagnosticSource service, which is actually a DiagnosticListener, just not registered as such. We just need to add a subscriber, and that’s all!
From the OnCommandExecuted method – by the way, you can call these methods whatever you like, as long as you keep the [DiagnosticName] attributes –, the result parameter will contain either a scalar (in the case of a ExecuteScalar/ExecuteScalarAsync call), a number (for ExecuteNonQuery/ExecuteNonQueryAsync) or a RelationalDataReader object (in the case of a ExecuteReader/ExecuteReaderAsync call). async, of course, will tell you exactly what version of the method was executed.
OnCommandExecuting is more interesting, because here we actually get access to the DbCommand that is about to execute the SQL command, and we can therefore modify its SQL or parameters. Finally, in OnCommandError you can get any exception that is caught during SQL execution.
There are other interception mechanisms, such as IQuerySqlGenerator and IQueryCompiler, and I will probably cover them in a future post. For now, hope this helps! 