En las dos últimas dos entradas he hablado sobre el nuevo bloque introducido en Entity Framework 6 para la realización de intercepciones. Aunque en principio solamente hemos hablado de lo básico, como por ejemplo los diferentes tracers, más aún con la nueva propiedad Database.Log, en realidad este bloque nos permite hacer cosas mucho más interesantes como por ejemplo el re-write de consultas. Si nos fijamos un poco en nuestra nueva clase DbInterceptor esta nos expone dos interfaces fundamentales IDbCommandInterceptor y IDbCommandTreeInterceptor de las que realmente podremos partir si queremos algo mucho más “a bajo nivel” dentro de la infraestructura de Entity Framework. Con el fin de ver algo diferente a los procesos de instrumentalización de las consultas vamos a intentar crear algún ejemplo de intercepción con reescritura de consulta utilizando estas dos interfaces.
IDbCommandInterceptor, reescritura de tu SQL
Como ya hemos comentado, esta interfaz nos ofrece los procesos de pre y post para las tareas habituales con la base de datos como por ejemplo son la ejecución de consultas y comandos. La idea para nuestra reescritura es poder introducir algún mecanismo que nos permita identificar un comando y proceder a su cambio, para verlo construiremos la siguiente clase CommandRewriter, la cual esta hecha a modo de ejemplo, intentaré poner pronto a vuestra disposición una implementación más apropiada de un sistema de reescritura de consultas.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
<span class="kwrd">public</span> <span class="kwrd">abstract</span> <span class="kwrd">class</span> CommandRewriter :IDbCommandInterceptor { <span class="kwrd">int</span> IDbCommandInterceptor.NonQueryExecuted(DbCommand command, <span class="kwrd">int</span> result, DbCommandInterceptionContext interceptionContext) { <span class="kwrd">return</span> result; } DbDataReader IDbCommandInterceptor.ReaderExecuted(DbCommand command, DbDataReader result, DbCommandInterceptionContext interceptionContext) { <span class="kwrd">return</span> result; } <span class="kwrd">object</span> IDbCommandInterceptor.ScalarExecuted(DbCommand command, <span class="kwrd">object</span> result, DbCommandInterceptionContext interceptionContext) { <span class="kwrd">return</span> result; } <span class="kwrd">void</span> IDbCommandInterceptor.NonQueryExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext) { <span class="kwrd">if</span> (IsCandidate(command)) { Rewrite(command); } } <span class="kwrd">void</span> IDbCommandInterceptor.ScalarExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext) { <span class="kwrd">if</span> (IsCandidate(command)) { Rewrite(command); } } <span class="kwrd">void</span> IDbCommandInterceptor.ReaderExecuting(DbCommand command, DbCommandInterceptionContext interceptionContext) { <span class="kwrd">if</span> (IsCandidate(command)) { Rewrite(command); } } <span class="kwrd">public</span> <span class="kwrd">abstract</span> <span class="kwrd">bool</span> IsCandidate(DbCommand command); <span class="kwrd">public</span> <span class="kwrd">abstract</span> <span class="kwrd">void</span> Rewrite(DbCommand command); } |
Si nos fijamos, en realidad, no hemos hecho absolutamente nada, simplemente hemos puesto una pequeña comprobación antes de la ejecución de los comandos que nos permita identificar si ese comando es candidato a ser reescrito. En caso afirmativo procedemos a la tarea. Un ejemplo evidente de esta reescritura se produce cuando queremos cambiar una consulta exacta por otra, por ejemplo para poder utilizar algún hint, cambiar un parámetro etc. para esto, podríamos hacer algo trivial como sigue:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<span class="kwrd">public</span> <span class="kwrd">abstract</span> <span class="kwrd">class</span> MatchCommandRewriter :CommandRewriter { <span class="kwrd">public</span> <span class="kwrd">abstract</span> <span class="kwrd">string</span> MatchedQuery { get; } <span class="kwrd">public</span> <span class="kwrd">abstract</span> <span class="kwrd">string</span> NewQuery { get; } <span class="kwrd">public</span> <span class="kwrd">override</span> <span class="kwrd">bool</span> IsCandidate(System.Data.Common.DbCommand command) { <span class="kwrd">return</span> String.Equals(command.CommandText, MatchedQuery, StringComparison.InvariantCultureIgnoreCase); } <span class="kwrd">public</span> <span class="kwrd">override</span> <span class="kwrd">void</span> Rewrite(System.Data.Common.DbCommand command) { command.CommandText = NewQuery; } } |
Ahora, que hemos creado estas simples bases, podríamos introducir una reescritura por ejemplo como la siguiente, que es solamente con fin ilustrativo, , en la que introducimos un hint NOLOCK en la consulta:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
<span class="kwrd">public</span> <span class="kwrd">class</span> CustomerNoLockQueryRewrite :MatchCommandRewriter { <span class="kwrd">public</span> <span class="kwrd">override</span> <span class="kwrd">string</span> MatchedQuery { get { <span class="kwrd">return</span> <span class="str">"SELECT rn[Extent1].[Id] AS [Id], rn[Extent1].[FirstName] AS [FirstName]rnFROM [dbo].[Customers] AS [Extent1]"</span>; } } <span class="kwrd">public</span> <span class="kwrd">override</span> <span class="kwrd">string</span> NewQuery { get { <span class="kwrd">return</span> <span class="str">"SELECT [Extent1].[Id] AS [Id], [Extent1].[FirstName] AS [FirstName] FROM [dbo].[Customers] AS [Extent1] WITH (NOLOCK) "</span>; } } } |
Una vez creado nuestro rewriter solamente nos queda asignarlo, para lo cual, como ya sabemos de otras entradas tenemos nuestra clase Interception.
|
1 |
Interception.AddInterceptor(<span class="kwrd">new</span> CustomerNoLockQueryRewrite()); |
|
1 |
  |
A lo largo de esta entrada hemos podido ver como los interceptores sirven para mucho mas que para las trazas de nuestras consultas y podemos tener una ganancia importante con su uso dentro de nuestras aplicaciones. En esta primera edición hemos visto la intercepción de nuestras consultas SQL, para la siguiente intentaremos ver como modificar nuestros arboles de consulta antes de generar el SQL.
Saludos
Unai