все-таки инджектить, то как потом использовать using? Или тогда не использовать using? И регистрировать SqlConnection в DI-контейнере, то как Singleton или не как Singleton?
это подозрительная идея, да. Зачем там инжект, ты подменять будешь коннекшн? Если для тестов, то сомневаюсь что в классе, который активно юзает SqlConnection можно будет чот кроме интеграционных тестов написать над ин-мемори бд или подобным
Почему подозрительная? Не для тестов. Сейчас есть ConnectionFactory, где каждый раз делается new SqlConnection, который потом используется в using. Может быть выпилить ConnectionFactory и зарегистрировать SqlConnection'ы в DI-контейнере?
если не для тестов зачем ты инжектишь? ради инжекта?) interface IOrderStorage GetOrder: OrderId -> Async<Order> CreateOrder: OrderCreate -> Async<OrderId> type OrderPostgreStorage(postgreCredentials) = let connection = CreatePostgreConnection(postgreCredentials) interface IOrderStorage with member GetOrder orderId = conn.Execute … … псевдо фшарпокод Вот тут инжектится то что надо классу для работы, тестировать его проще простого - кинул креденшлы до постгре бд, потестил. Хоть в докере подымай сам, хоть в тестконтейнере, хоть в локалхосте Всем остальным интерфейс, пусть мокают если надо. Зачем инжектить просто так?
нет, не ради инджекта, а для оптимизации - чтобы каждый раз не пересоздавать SqlConnection
в адо.нет уже встроен пулинг, не надо заниматься бесполезной оптимизацией...
Да я и рад бы, но возникает такой Exception: The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached. Утечки connection'ов я проверил вроде бы нет
так вроде бы или нет?) Боюсь у тебя проблема
Вроде бы - потому что я просто глазами код просмотрел. Везде connection'ы используются через using
Обсуждают сегодня