Функции Azure: привязка к DocumentClient вместо статического экземпляра - что рекомендуется? - PullRequest
1 голос
/ 24 мая 2019

Я знаю, как связывать запросы напрямую с функцией Azure и использовать триггеры Cosmos DB в функциях.

Однако я ищу направление вокруг использования DocumentClient (пакет Nuget Microsoft.Azure.Cosmos) напрямую.

  1. Есть документация , которая объясняет, как использовать повторностатический экземпляр клиента между выполнениями.
  2. Также можно получить экземпляр DocumentClient в качестве привязки, добавив [DocumentDB("test", "test", ConnectionStringSetting = "CosmosDB")] DocumentClient client к параметрам функции.
  3. Наконец, можно создатьDocumentClient экземпляр в теле функции: var client = new DocumentClient(...).

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

Вопросы

  • Функции Azure имеют ограничение соединения ( обсуждается здесь ),Применимо ли это также при использовании подхода 2 (привязка к клиенту)?
  • Каковы преимущества и недостатки использования подхода 2 (привязка) по сравнению с 1 (статический)?
  • В чем преимущество привязкик запросу SQL по сравнению с привязкой к DocumentClient и созданием запроса в теле функции?

Ответы [ 2 ]

1 голос
/ 25 мая 2019

Существует еще один способ использования DocumentClient. Начиная с версии 1.0.28 файла Microsoft.NET.Sdk.Functions, теперь можно использовать класс FunctionsStartup, чтобы инициализировать DocumentClient один раз, а затем зарегистрировать его для DI (внедрение зависимости), а затем каждый раз использовать один и тот же экземпляр.

Класс FunctionsStartup задокументирован здесь . И лучшее объяснение: здесь .

В методе конфигурирования вашего стартапа соберите ваш клиент.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;
[assembly: FunctionsStartup(typeof(MyApp.Startup))]
namespace MyApp
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            IDocumentClient client = GetCustomClient();
            builder.Services.AddSingleton<IDocumentClient>(client);
        }
}

Затем его можно внедрить в конструктор функции и использовать методы.

public class MyFunction
{
    private IDocumentClient _client;

    public MyFunction(IDocumentClient client)
    {
        _client = client;
    }

    [FunctionName("MyFunction")]
    public async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
        ILogger log)
    {
        // use _client here.
    }
}

Когда Azure создает экземпляр этого класса для обслуживания запроса, он передает экземпляр IDocumentClient, созданный в классе FunctionsStartup.

Эта стратегия позволяет повторно использовать один и тот же экземпляр DocumentClient. Единственная особенность этого клиента не в том, чтобы сделать его статичным, а в том, чтобы мы создали его только один раз. Это также помогает с тестируемостью, поскольку тесты могут внедрить другой экземпляр IDocumentClient.

1 голос
/ 24 мая 2019

Эта статья дает хороший пример для статического клиента.

Мы все знаем горести этого подхода для HttpClient (и если вы не читайте его сразу после этой статьи!) тот же эффект здесь: если функция получает большой объем триггеры, мы не только будем наказывать производительность наших вызовы базы данных с издержками инициализации, но память потребление возрастет, и мы можем даже понести истощение сценарии.

На ваши вопросы 2 и 3: Большим преимуществом использования привязки является простота. Все создание клиентов и т. Д. Абстрагируется от вас. Кон это, конечно, контроль. Здесь является хорошим примером использования пользовательского клиента.

Использование SQL-запроса вместо DocumentClient - это еще один шаг в плане абстракции.

...