Dapper не может найти отображение POCO из запроса SELECT CASE - PullRequest
0 голосов
/ 20 ноября 2018

Я извлекаю информацию из базы данных SQL Server, используя Dapper.POCO для рассматриваемой информации ниже.

public class Client
    {
        public string ShortName { get; set; }
        public string ContactDetail { get; set; }
        public string Street { get; set; }
        public string District { get; set; }
        public string Town { get; set; }
        public string County { get; set; }
        public string Postcode { get; set; }
    }

Когда я извлекаю информацию для вышеуказанного объекта, используя запрос ниже, вся информация отображается правильно, кроме следующей строки max(case when cd.Type = 1 OR cd.Type = 2 then cd.Detail end) as 'ContactDetail' Я считаю, что этоможет быть потому, что я не просто извлекаю данные из столбца таблицы, а вместо этого выполняю некоторую обработку с использованием предложения CASE заранее, и поэтому Dapper не может найти правильное место для сопоставления информации.

Я думал, включаяПредложение AS поможет Dapper найти правильное сопоставление, но на самом деле это не сработает.

Как изменить запрос, чтобы Dapper мог правильно сопоставить данные ContactDetail?

select 
tp.ShortName as 'ShortName', 
max(case when cd.Type = 1 OR cd.Type = 2 then cd.Detail end) as 'ContactDetail',
tp.Street, 
tp.District, 
tp.Town, 
tp.County, 
tp.PostCode
... (rest of query snipped as unneeded)

Я знаю, что запрос работает правильно, так как я могу запустить его в SSMS, и он возвращает правильную информацию.

Ответы [ 2 ]

0 голосов
/ 21 ноября 2018

Dapper не интересуется и не знает, что находится внутри запроса - он только заботится о форме результатов.Итак: что бы ни происходило - это часть запроса.

Мои догадки будут:

  • данные действительно отсутствуют и / или null
  • что-то делать с обработкой null и объединением нулей, возможно, с max усложняющими вещами

Обратите внимание, что вы не можете просто сравнить с выводом SSMS, потому что SSMSи ADO.NET (SqlClient) может иметь различные значения по умолчанию для параметра SET, которые могут иметь существенные, но незначительные различия для некоторых запросов.

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

Повторяю, хотя:

Я сильно подозреваю, что если вы выполните тот же запрос с помощью ExecuteReader или подобным, вы обнаружите, что значениевозвращение в это положение действительно null (или DBNull).

0 голосов
/ 20 ноября 2018

Я почти уверен, что проблема в том, что если вы используете маппер объектов в Dapper (т.е. Client в <>), он просто будет искать эти столбцы в соответствующей таблице.«ContactDetail» не существует (он является производным), поэтому он не найдет его.

У вас есть несколько вариантов здесь, в зависимости от ваших данных и варианта использования.

  • Получите необработанные данные из Dapper, а затем используйте Linq (или аналогичный) для получения ContactDetail с использованием логики в программе.

  • Напишите хранимую процедуру на основе вашего запроса ииспользуйте Dapper для его запуска

  • Используйте команду Query Dapper для запуска вашего оператора SQL вместо попытки напрямую отобразить объект.

Позвольте мнезнать, если вы застряли на этом, или требуется дальнейшее объяснение.

...