2012-05-22 2 views
6

В принципе, я хочу использовать «хороший» синтаксис Dapper для хранимой процедуры, без необходимости вручную использовать exec MySproc @p1, @p2, @p3, @p4 и т. Д., Но мне нужно иметь возможность передавать строго типизированный объект с различными наборами свойств и иметь этот объект для отображения параметров. Я знаю, что могу сделать это с анонимным объектом, но сценарий, о котором я думаю, будет чем-то вроде сложной формы поиска, в которой можно искать несколько полей, а в соответствующей хранимой процедуре может быть довольно много параметров (многие из них по умолчанию).Поддерживает ли Dapper строго типизированные объекты с помощью хранимой процедуры?

В идеале я хотел бы быть в состоянии сделать что-то вроде этого:

var cust = new Customer(); 
cust.FirstName = ... 
cust.LastName = ... 

// using .NET 3.5 so need to use ugly syntax :(
var result = connection.Query<Customer>("MySproc", cust, null, false, null, CommandType.StoredProcedure).Single(); 

однако, что не работает и выдает ошибку, потому что мой объект Клиент может иметь десяток или более свойств, и я В этом случае мы будем искать только два; Кажется, что Dapper просто проверяет каждое свойство и присваивает значение, предполагая, что в sproc есть соответствующий параметр, если этого не может быть.

я могу сделать что-то похожее на это, используя PetaPoco (проходят в строго типизированный объект или анонимный объект), но я искал что-то немного более отведенной чем PetaPoco есть.

Является ли то, что я хочу сделать в Dapper (или другой микро-ORM? Я не могу использовать NHibernate или супертяжелый ORM), или есть способ, которым я пропускаю одну и ту же функциональность, не имея необходимости писать exec с тем, что может быть дюжиной параметров?

ответ

9

Если вы хотите, чтобы указать Params вам нужно будет сделать это явно:

var result = connection.Query<Customer>("MySproc", 
    new {cust.Id, cust.Name}, // specify the params you want to give it. 
    null, 
    false, 
    null, 
    CommandType.StoredProcedure).Single(); 

Мы не делаем sp_help PARAMS нюхать для проков хотя вы могли бы потенциально построить помощник, который делает это и позволяет для запуска: cust.ToProcParams('MySproc')

В качестве альтернативы, если вы хотите создать этот параметр динамически, вы можете использовать.

var dp = new DynamicParameters(); 
dp.Add("Id", cust.Id); 
dp.Add("Name", cust.Name); 
var result = connection.Query<Customer>("MySproc", 
     dp, 
     null, 
     false, 
     null, 
     CommandType.StoredProcedure).Single(); 
+0

Вот чего я боялся, так как использование анонимных объектов не позволяет мне строить объект динамически на основе входных данных. Однако идея вспомогательного метода интересна. –

+1

@WayneM см. Мое редактирование ... –

+0

Теперь это выглядит интересно. Мне придется поиграть с этим и посмотреть, как это работает. Большое спасибо, Сэм! –

2

Если вы используете SQL Server, ознакомьтесь с Insight.Database. https://github.com/jonwagner/Insight.Database/wiki Он больше ориентирован на хранимые процедуры и использует SqlDeriveParameters для определения соответствия между объектами и хранимыми процедурами.

ПРИМЕЧАНИЕ: в настоящее время требуется .NET 4.0, но если вы действительно заинтересованы в версии .NET 3.5, я могу видеть, насколько это будет сложно.

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