Підключення до бази даних - чи повинні вони передаватися як параметр?

У нас є система, згідно з якою підключення до бази даних отримується один раз за допомогою загального методу і передається через відповідний клас, який буде використовуватися. Є сумніви, що передача підключення до бази даних як параметр до різних класів спричинить проблему, тому я перевіряю тут, чи є це насправді життєздатним, і чи є кращі зразки для цього?

Я знаю, що є кілька інструментів ORM, щоб зробити наполегливість, але ми все ще не можемо вступити в це.

Будь-який відгук вітається, дякую.

Так, безпечно пройти навколо зв'язку. Ви обробляєте з'єднання у зовнішньому блоці управління. У цьому немає нічого небезпечного.

Небезпечно - це написання коду, який не гарантує належне розміщення з'єднання. Забуття очистити ресурс не пов'язане з передачею його навколо. Ви можете так само легко написати код, який залишає звисне з'єднання, не передаючи його нікуди.

У C ++ ви захищені RAII, якщо ви виділяєте в стеку або використовуєте смарт-покажчики. У C # складіть жорстке правило, що всі одноразові об'єкти (наприклад, з'єднання) оголошуються в блоці "використовуючи". У Java прибирайте за допомогою логіки спробу. Проведіть огляд коду на весь код рівня даних, щоб забезпечити це.

Найбільш поширений випадок використання, коли у вас є кілька операцій, які можна комбінувати в багатьох перестановках. І кожна з цих перестановок повинна бути атомною транзакцією (всі успішні або відкатні). тоді вам слід передати транзакцію (а отже, і відповідне з'єднання) навколо всіх методів.

Припустимо, у нас є багато дій foobar (), які можна комбінувати різними способами як атомні транзакції.

//example in C#
//outer controlling block handles clean up via scoping with "using" blocks.
using (IDbConnection conn = getConn())
{
    conn.Open();
    using (IDbTransaction tran = conn.BeginTransaction())
    {
        try
        {//inner foobar actions just do their thing. They don't need to clean up.
            foobar1(tran);
            foobar2(tran);
            foobar3(tran);
            tran.Commit();
        }
        catch (Exception ex)
        { tran.Rollback(); }
    }
}//connection is returned to the pool automatically

До речі, ви хочете відкрити з'єднання якомога пізніше, розпоряджайтеся ними якнайшвидше. Ваші товариші по команді можуть мати рацію, якщо ви ставитесь до з'єднань як до членів об'єкта, представляючи їх як непотрібний стан і залишаючи з'єднання відкритими набагато довше, ніж потрібно. Але акт передачі з'єднання або транзакції як параметр не є за своєю суттю помилковим.

До речі. Залежно від підтримки вашої мови для функцій першого класу, ви можете здійснити список дій foobar (). Таким чином, одна функція могла обробляти всі перестановки дій. Усунення дублювання зовнішнього керуючого блоку для кожної перестановки.

Це здається, що ви після ін'єкції залежності . Тобто, об'єднане з'єднання створюється один раз і вводиться там, де це потрібно. Безумовно, проходження з'єднання через параметр методу - це один із способів введення залежності, але контейнер IoC, такий як Guice, PicoContainer або Spring - це інший (безпечніший) спосіб зробити це.

Використання DI означає, що ви можете акуратно завершити логіку навколо створення, відкриття, використання та закриття з'єднання - далеко від вашої основної бізнес-логіки.

Spring JDBC та інші - це більш прикладні приклади виконання подібної поведінки для вас

Проходження навколо баз даних, а не даних може призвести до проблем. У цій мірі, коли це практично, не передайте базу даних, якщо тільки не можна гарантувати належну гігієну бази даних.

Проблема при обходженні речей із бази даних полягає в тому, що вона може бути неохайною. Я бачив більше однієї помилки в коді з тим, хто проходить навколо з’єднання з базою даних, коли хтось захоплює набір результатів і зберігає в локальному об'єкті (набір результатів, все ще підключений до бази даних), а потім зв'язує курсор у база даних протягом значного часу. Інший екземпляр хтось передав набір результатів комусь іншому (який тоді був схований), а потім метод, який передав набір результатів, закрив його (і заяву), що призвело до помилок, коли інші методи намагалися працювати з набором результатів, який більше не було.

Все це випливає з неповаги до бази даних, з'єднання, заяви, набору результатів та їх життєвих циклів.

Щоб уникнути цього, існують існуючі шаблони та структури, які краще грають з базами даних і не мають речей із базами даних, щоб вийти з класів, в яких вони обмежені. Дані надходять, дані виходять, база даних залишається поставленою.

Передача Connectionпримірників навколо зазвичай не є проблемою, хоча в більшості ситуацій тільки реалізація DAO повинна мати щось спільне з ними. Тепер, якщо ваша проблема полягає в тому, що з'єднання не будуть закриті після використання, це насправді легко виправити: Connectionоб’єкт потрібно закрити на тому ж рівні, на який він відкрився, тобто тим же методом. Я особисто використовую таку схему коду:

final Connection cnx = dataSource.getConnection();
try {
    // Operations using the instance
} finally {
    cnx.close();
}

Таким чином я забезпечую, щоб усі з'єднання були завжди закритими, навіть якщо виняток буде передано всередині блоку. Я фактично іду до тих пір, поки використовую точно таку ж схему для Statementі ResultSetекземплярів, і все поки плавне плавання досі.

Редагувати 2018-03-29: Як зазначено користувачем1156544 у коментарях нижче, починаючи з Java 7, слід використовувати перевагу конструкції спробувати ресурсів. Використовуючи його, шаблон коду, який я надав у своїй початковій відповіді, можна спростити так:

try (final Connection cnx = dataSource.getConnection()) {
    // Operations using the instance
}

є компроміс робити речі таким чином, а не використовувати сингл, який можна отримати за потреби. У минулому я робив речі обома способами.

Загалом, вам потрібно подумати про наслідки управління підключеннями до бази даних, і це може бути, а може бути, не ортогональним для використання запитів до бази даних. Наприклад, якщо у вас є одне db-з'єднання для даного екземпляра програми, і воно закривається, коли не використовується, це буде ортогональним. Поставте управління в однотонний клас і не передайте його. Це дозволяє керувати db-з'єднанням у міру необхідності. Наприклад, якщо ви хочете закрити з'єднання під час кожної комісії (і повторно відкрити при наступному дзвінку), це зробити простіше в одиночному режимі, оскільки API для цього може бути централізованим.

З іншого боку, припустимо, вам потрібно керувати пулом з'єднань, де для даного дзвінка може знадобитися будь-яке довільне з'єднання. Це може статися, наприклад, при здійсненні розподілених транзакцій на декількох серверах. У цьому випадку вам зазвичай набагато краще передавати об’єкт db-з'єднання, ніж ви працюєте з одинаковими кнопками. Я думаю, що це звичайно рідше, але немає нічого поганого в тому, коли робити це потрібно.