Dapper.NET Valore Inline


Esempio

A volte la convenienza di un parametro (in termini di manutenzione ed espressività) può essere superata dal suo costo in termini di prestazioni per trattarlo come un parametro. Ad esempio, quando la dimensione della pagina è fissata da un'impostazione di configurazione. O un valore di stato è abbinato a un valore enum . Tenere conto:

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 });

L'unico parametro reale qui è customerId - gli altri due sono pseudo-parametri che in realtà non cambieranno. Spesso il RDBMS può fare un lavoro migliore se rileva questi come costanti. Dapper ha una sintassi speciale per questo - {=name} invece di @name - che si applica solo ai tipi numerici. (Ciò minimizza qualsiasi superficie di attacco dall'iniezione SQL). Un esempio è il seguente:

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

Dapper sostituisce i valori con i letterali prima di emettere l'SQL, quindi l'RDBMS vede effettivamente qualcosa del tipo:

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

Ciò è particolarmente utile quando si consente ai sistemi RDBMS non solo di prendere decisioni migliori, ma di aprire piani di query che i parametri attuali impediscono. Ad esempio, se un predicato di colonna è contrario a un parametro, non è possibile utilizzare un indice filtrato con valori specifici su tali colonne. Questo perché la prossima query potrebbe avere un parametro diverso da uno di quei valori specificati.

Con valori letterali, Query Optimizer è in grado di utilizzare gli indici filtrati poiché sa che il valore non può cambiare nelle query future.