запросы oData и одноразовое SQL-соединение

Question

При внедрении службы oData с использованием WebApi 2.0 стандартная практика заключается в том, чтобы выставить IQueryable из вашей службы в действие ApiControllers. Таким образом, структура может применить запрос oData к вашему IQueryable.

В настоящее время я читаю, как важно всегда вызывать Dispose при подключении к базе данных. Предпочтительно, используя «используя» заявление так:

using (SqlConnection connection = new SqlConnection(connectionString)) 
{ 
    connection.Open(); 
    // Execute operations against the database 
} // Connection is automatically closed. 

Мой вопрос: Когда соединение с базой данных закрыты в случае OData? Вы, очевидно, не можете распоряжаться этим соединением самостоятельно, прежде чем среда применит запрос oData - это вызовет исключение.

Сопутствующая тема была бы: вы согласны с тем, чтобы разоблачить IQueryable <> от ваших услуг? Я читал об этом, и это долгая дискуссионная проблема - люди утверждают, что работа с базой данных должна содержаться в репозитории, в то время как другие хотели бы предоставить свободу запросов клиентам услуг. Я согласен с тем, что содержит запросы в репозитории, но в случае oData мне не нравится чрезмерно усложнять ситуацию, если инфраструктура проверяет IQueryable, тогда я даю ей IQueryable. Как вы думаете ?

Answer 1

Обычно в таких случаях соединение с базой данных закрывается при установке экземпляра контроллера asp.net. Предположим, вы используете контекст Entity Framework для выполнения запросов. Затем вы создаете (возможно, лениво) этот контекстный экземпляр при необходимости, а затем переопределяете метод Dispose ODataController и удаляете его там. Например, взгляните на эту статью: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/create-an-odata-v4-endpoint.

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