Dapper с динамическими переменными не будет работать без отображения.Это ломает SQL.Как использовать Dapper с большим запросом SQL?

Question

Допустим, у меня был сохраненный процесс в MS SQL.Теперь я перешел на MySQL и хочу сохранить все запросы SQL внутри основного приложения C # asp.net.

Проблема начинается с более крупных запросов, где могут быть динамические внутренние переменные SQL.

Т.е.Select @TypeId := TypeId, @StartDate := StartDate From Test_test Where Id = @Id

В этом примере @Id должен отображаться Dapper (эта переменная передается из DAL в базу данных MySQL), однако @TypeId и @StartId не должны отображаться.

1. Существует намного больше динамических переменных, созданных только для SQL-запроса

2. Отображение пустого значения прервет запрос, т. Е. Вот результаты SQL

   NULL := StartDate вместо @StartDate := StartDate

Как я могу использовать dapper с SQL-запросами, когда запрос создает динамические переменные, которые не должны отображаться Dapper?

Answer 1

Не должно быть никаких проблем с использованием переменных SQL в запросе с Dapper, если вы включите AllowUserVariables=true в строку подключения. Это позволяет клиентской библиотеке «игнорировать» @TypeId и @StartDate в вашем SQL и не требовать их указания в коллекции MySqlCommand.Parameters.

Пока вы не включаете свойства с этими именами в анонимный объект, который вы передаете Dapper (т.е. не делаете new { StartDate = DateTime.Now, TypeId = 1 }), Dapper не будет создавать никаких параметров с этими именами, не будет отображаться любые значения для них, и будет передавать SQL через MySQL Server для оценки в качестве серверных переменных.