Looking for dapper Keywords? Try Ask4Keywords

Dapper.NET バリューインライン化


場合によっては、保守性や表現力の面でパラメータの利便性が、パラメータとして扱うための性能のコストよりも凌駕されることがあります。たとえば、ページサイズが構成設定によって固定されている場合などです。または、ステータス値がenum値と一致しています。検討してください:

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

実際の唯一パラメータはcustomerId 。他の2つは実際には変更されない疑似パラメータです。これらを定数として検出すると、RDBMSはしばしばより良い仕事をすることができます。 Dapperには、 @name {=name}代わりに - {=name}という特殊な構文があります。これは数値型にのみ適用されます。 (これにより、SQLインジェクションからの攻撃面が最小限に抑えられます)。例は次のとおりです。

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

Dapperは、SQLを発行する前に値をリテラルに置き換えるので、RDBMSは実際に次のように見えます。

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

これは、RDBMSシステムがより良い意思決定を行うだけでなく、実際のパラメータが回避するクエリプランを開くときに特に便利です。たとえば、列述語がパラメータに対抗する場合、その列に特定の値を持つフィルタされた索引は使用できません。これは、 次の照会に、指定された値の1つから離れたパラメーターがある可能性があるためです。

リテラル値では、クエリオプティマイザは、将来のクエリで値が変更できないことがわかっているので、フィルタされたインデックスを使用できます。