Looking for dapper Keywords? Try Ask4Keywords

Dapper.NET Inlining wartości


Przykład

Czasami wygoda parametru (pod względem konserwacji i ekspresji) może być przeważona kosztem wydajności, aby traktować go jako parametr. Na przykład, gdy rozmiar strony jest ustalony przez ustawienie konfiguracji. Lub wartość statusu jest dopasowywana do wartości enum . Rozważać:

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

Jedynym prawdziwym parametrem jest tutaj identyfikator customerId - pozostałe dwa to pseudo-parametry, które tak naprawdę się nie zmienią. Często RDBMS może wykonać lepszą robotę, jeśli wykryje je jako stałe. Dapper ma do tego specjalną składnię - {=name} zamiast @name - która dotyczy tylko typów numerycznych. (Minimalizuje to wszelką powierzchnię ataku po wstrzyknięciu SQL). Przykład jest następujący:

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

Dapper zastępuje wartości literałami przed wydaniem SQL, więc RDBMS faktycznie widzi coś takiego:

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

Jest to szczególnie przydatne, gdy pozwala się systemom RDBMS nie tylko podejmować lepsze decyzje, ale także otwierać plany zapytań, którym zapobiegają rzeczywiste parametry. Na przykład, jeśli predykat kolumny jest zgodny z parametrem, wówczas nie można użyć filtrowanego indeksu z określonymi wartościami dla tych kolumn. Wynika to z faktu, że następne zapytanie może zawierać parametr oprócz jednej z tych określonych wartości.

Przy wartościach literalnych optymalizator zapytań może korzystać z filtrowanych indeksów, ponieważ wie, że wartość nie może się zmienić w przyszłych zapytaniach.