Я использую объект DynamicParamters Dapper с аргументом шаблона для создания аргументов с моими сущностями. После вызова хранимой процедуры я получаю следующую ошибку: «Процедура или функция sp_MemberSave имеет слишком много аргументов». У меня есть дополнительные свойства для некоторых моих сущностей для бизнес-логики и т. д. Есть ли способ убедиться, что dapper передает только те параметры, которые являются фактическими параметрами для хранимой процедуры? Похоже, что Dapper сначала прочитает хранимую процедуру, а затем установит параметры, таким образом, он будет использовать только те, которые верны. Как ограничить параметры, используя возможности шаблона?
Изысканная процедура или функция sp_XXXX имеет слишком много аргументов.
Ответы (2)
Попробуйте создать анонимный тип соответствующих параметров из вашего объекта... Если в вашем классе есть A, B, C и D, а вам нужны только A и B:
DynamicParameters(new { A = entity.A, B = entity.B });
Могу ли я быть очень ясным по сценарию здесь? если вы просто передаете объект (а не DynamicParameters
), он выполняет этот анализ; то есть conn.Execute("some sql", someEntity);
- тогда он добавит только те члены someEntity
, которые, как он видит, используются в SQL. Могут быть некоторые ложные срабатывания, поскольку он не выполняет полный лексический анализ SQL, поэтому параметр в комментариях, т. е.:
-- removed by Fred: where row.Date < @StartDate
все равно будет включен (поэтому в приведенном выше примере участник StartDate
будет иметь право на участие, даже если он, вероятно, на самом деле не нужен).
Однако; DynamicParameters
в настоящее время доверяет пользовательской реализации. Я полагаю, что мы могли перенести проверку анализа параметров на более поздний этап, но я бы предпочел сначала понять весь сценарий.
exec
) — такое я вижу довольно часто — отсюда и желание увидеть очень наглядный пример. Но одно можно сказать наверняка: dapper никогда не попытается сначала прочитать хранимую процедуру.
- person Marc Gravell; 21.10.2013