Dapper.NET Valor en línea


Ejemplo

A veces, la conveniencia de un parámetro (en términos de mantenimiento y expresividad) puede ser superada por su costo en el rendimiento para tratarlo como un parámetro. Por ejemplo, cuando el tamaño de la página está fijado por una configuración. O un valor de estado coincide con un valor enum . Considerar:

var orders = connection.Query<Order>(@"
select top (@count) * -- these brackets are an oddity of SQL Server
from Orders
where CustomerId = @customerId
and Status = @open", new { customerId, count = PageSize, open = OrderStatus.Open });

El único parámetro real aquí es customerId , los otros dos son pseudo parámetros que no cambiarán realmente. A menudo, el RDBMS puede hacer un mejor trabajo si detecta estas constantes. Dapper tiene una sintaxis especial para esto - {=name} lugar de @name - que solo se aplica a los tipos numéricos. (Esto minimiza cualquier superficie de ataque de la inyección de SQL). Un ejemplo es el siguiente:

var orders = connection.Query<Order>(@"
select top {=count} *
from Orders
where CustomerId = @customerId
and Status = {=open}", new { customerId, count = PageSize, open = OrderStatus.Open });

Dapper reemplaza los valores con literales antes de emitir el SQL, por lo que RDBMS realmente ve algo como:

select top 10 *
from Orders
where CustomerId = @customerId
and Status = 3

Esto es particularmente útil cuando se permite que los sistemas RDBMS no solo tomen mejores decisiones, sino que también abran planes de consulta que impiden los parámetros reales. Por ejemplo, si un predicado de columna es contra un parámetro, entonces no se puede usar un índice filtrado con valores específicos en esas columnas. Esto se debe a que la siguiente consulta puede tener un parámetro aparte de uno de esos valores especificados.

Con valores literales, el optimizador de consultas puede hacer uso de los índices filtrados, ya que sabe que el valor no puede cambiar en futuras consultas.