Looking for dapper Keywords? Try Ask4Keywords

Dapper.NET Wert Inlining


Beispiel

Manchmal kann die Bequemlichkeit eines Parameters (in Bezug auf die Wartung und Ausdruckskraft) durch seine Kosten in der Leistung aufgewogen werden, um ihn als Parameter zu behandeln. Zum Beispiel, wenn die Seitengröße durch eine Konfigurationseinstellung festgelegt wird. Oder ein Statuswert wird mit einem enum abgeglichen. Erwägen:

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

Der einzige echte Parameter hier ist customerId - die anderen beiden sind Pseudo-Parameter, die sich nicht wirklich ändern. Häufig kann das RDBMS eine bessere Arbeit leisten, wenn es diese als Konstanten erkennt. Dapper hat hierfür eine spezielle Syntax - {=name} anstelle von @name - die nur für numerische Typen gilt. (Dies minimiert jegliche Angriffsfläche durch SQL-Injection). Ein Beispiel ist wie folgt:

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

Dapper ersetzt Werte durch Literale, bevor SQL ausgegeben wird. Das RDBMS sieht also Folgendes:

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

Dies ist besonders nützlich, wenn RDBMS-Systeme nicht nur bessere Entscheidungen treffen, sondern auch Abfragepläne öffnen können, die durch tatsächliche Parameter verhindert werden. Wenn zum Beispiel ein Spaltenprädikat einen Parameter betrifft, kann ein gefilterter Index mit bestimmten Werten für diese Spalten nicht verwendet werden. Dies liegt daran, dass die nächste Abfrage einen Parameter außer einem dieser angegebenen Werte enthalten kann.

Mit Literalwerten kann das Abfrageoptimierungsprogramm die gefilterten Indizes verwenden, da es weiß, dass sich der Wert in zukünftigen Abfragen nicht ändern kann.