Добавление динамического SQL-запроса в QueryOver

У меня есть следующий запрос, который работает для меня:

IList<info> result = 
QueryOver<info>()
.Where(row => row.Timestamp >= fromDate)
.And(row => row.Timestamp <= toDate)
.OrderBy(row => row.Timestamp).Asc
.Skip(startRow).Take(count).List();

Мне нужно расширить его, получив от клиента дополнительную строку запроса SQL и добавив ее к моему запросу следующим образом:

    IList<info> result = 
        QueryOver<info>()
        .Where(row => row.Timestamp >= fromDate)
        .And(queryString)
        .And(row => row.Timestamp <= toDate)
        .OrderBy(row => row.Timestamp).Asc
        .Skip(startRow).Take(count).List();

string queryString = "AND name='haim' And number=1"

Можно ли добавить QueryOver строку динамического запроса?


person Haimon    schedule 21.04.2013    source источник
comment
почему ты хочешь сделать это?   -  person Phill    schedule 21.04.2013


Ответы (3)


Сомневаюсь, что это возможно из коробки. Но с некоторой настройкой вы можете сделать это

  1. Получите SQL из вашего QueryOver<>. Следуйте принятому ответу на этот вопрос < /а>
  2. Объедините это с вашим sql, отправленным клиентом
  3. Используйте NH для запуска простого SQL. Обратитесь к принятому ответу на этот вопрос о том, как это сделать.
person Suhas    schedule 21.04.2013

Короткий ответ: вы можете:

string queryString = "name='haim' And number=1";
var query = Session.QueryOver<info>().And(NHibernate.Criterion.Expression.Sql(queryString));

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

person Jaguar    schedule 22.03.2014

Я бы добавил, что не рекомендуется генерировать sql где-то еще и отправлять его на выполнение. Я знаю, что может быть сложно абстрагировать сценарии WHERE в классах, но с NET4 это намного быстрее делать с динамическими классами.

Поэтому я говорю, что это плохая практика, потому что вы не инкапсулируете свой запрос в один слой. Вам следует.

Ужасным последствием является, очевидно, отсутствие прочной связи между двумя частями, что делает это решение очень хрупким. Если один из них изменится, вы должны знать, что другой необходимо обновить, и так далее. Одна или две команды разработчиков — это нормально, но большие команды от этого пострадают.

Просто мои два цента.

person Kat Lim Ruiz    schedule 21.03.2014