2013-06-18 2 views
3

Я использую Dapper's DynamicParamters объект с аргументом шаблона для генерации аргументов с моими сущностями. После того, как я позвоню в свою хранимую процедуру, я получаю следующую ошибку: «Процедура или функция sp_MemberSave содержит слишком много аргументов». У меня есть дополнительные свойства для некоторых моих объектов для бизнес-логики и т. Д. Есть ли способ убедиться, что dapper передает только параметры, являющиеся фактическими параметрами хранимой процедуры? Похоже, что Dapper сначала прочитал хранимую процедуру, а затем установил параметры, таким образом, он будет использовать только те, которые являются правильными. Как я могу ограничить параметры с помощью возможностей шаблона?Dapper «Процедура или функция sp_XXXX содержит слишком много аргументов».

+0

Вы передаете свой объект (экземпляр вашего класса) в качестве параметра хранимой процедуры? –

+0

Я вызываю DynamicParameters (entity), где entity является одним из моих объектов. Мои мысли состояли в том, что это создало бы коллекцию Parameters, читая объект и генерируя коллекцию Parameters. Я также думал, что он игнорирует любые параметры, которые не являются фактическими сохраненными параметрами prcoedure. Это так? – user1790300

ответ

3

Попробуйте создать анонимный тип соответствующих параметров из вашего объекта ... Если ваш класс имеет A, B, C, и D, и вам нужно только А и Б:

DynamicParameters(new { A = entity.A, B = entity.B }); 
+0

Я надеялся, что мне не нужно было так поступать, так как есть много параметров. Много. – user1790300

+0

Я понимаю. Мы написали обертку для Dapper в моей компании, у которой есть некоторые опрятные функции ... один из которых добавляет атрибут [NotParameter], который позволяет оболочке игнорировать свойства/поля. – Haney

+0

Я просматривал их код, чтобы найти место для фильтрации параметров по мере их добавления, но раздел, который выполняет добавление, казался немного трудным для выполнения :-). – user1790300

0

Могу ли я быть Очень ясно, сценарий здесь? если вы просто передаете объект (а не DynamicParameters), он делает сделать этот анализ; то есть conn.Execute("some sql", someEntity); - после этого будут добавлены только члены someEntity, которые он может видеть, которые используются в SQL. Там могут быть некоторые ложных срабатываний, так как она не выполняет полный лексический анализ SQL, поэтому параметр в комментариях, а именно:

-- removed by Fred: where row.Date < @StartDate 

по-прежнему будет включен (так в приведенном выше примере, член StartDate бы иметь право, хотя это, вероятно, не фактически необходимо).

Однако; DynamicParameters в настоящее время доверяет пользовательской реализации. Я полагаю, что может переместить проверку анализа параметров после этой точки, но я бы предпочел сначала понять весь сценарий.

+0

«... он делает этот анализ» - делает ли он анализ хранимых процедур (что и использует OP)? – Joe

+0

@Joe, если командный тип говорит хранимую процедуру, то нет: это не так.Тем не менее, также можно использовать хранимые процедуры через текстовый командный тип (через 'exec') - я вижу это довольно часто - отсюда желание увидеть очень ясный пример. Но одно можно сказать наверняка: dapper никогда не попытается «сначала прочитать хранимую процедуру» –

+0

спасибо за разъяснение. – Joe

Смежные вопросы