Looking for dapper Keywords? Try Ask4Keywords

Dapper.NET Värdeinlining


Exempel

Ibland kan bekvämligheten hos en parameter (när det gäller underhåll och uttrycksförmåga) uppvägas av dess kostnad i prestanda för att behandla den som en parameter. Till exempel när sidstorleken är fixerad av en konfigurationsinställning. Eller ett enum matchas med ett enum . Överväga:

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

Den enda riktiga parametern här är customerId - de andra två är pseudoparametrar som faktiskt inte kommer att ändras. Ofta kan RDBMS göra ett bättre jobb om det upptäcker dessa som konstanter. Dapper har en speciell syntax för detta - {=name} istället för @name - som endast gäller numeriska typer. (Detta minimerar all attackyta från SQL-injektion). Ett exempel är följande:

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

Dapper ersätter värden med bokstäver innan han utfärdar SQL, så RDBMS ser faktiskt något som:

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

Detta är särskilt användbart när man tillåter RDBMS-system att inte bara fatta bättre beslut utan också öppna frågeformer som faktiska parametrar förhindrar. Till exempel, om en kolumnpredikat är mot en parameter, kan inte ett filtrerat index med specifika värden på de kolumnerna användas. Det beror på att nästa fråga kan ha en parameter förutom ett av de angivna värdena.

Med bokstavliga värden kan sökoptimeraren använda de filtrerade indexen eftersom den vet att värdet inte kan ändras i framtida frågor.