Щоб інкапсулювати з'єднання з базами даних у бізнес-об'єкти чи ні? - .net, база даних, дизайн

Я зазвичай хотів би самостійно створити з'єднання з базою даних і керувати його життя вручну за допомогою `use {}". Наприклад:

SqlConnection sqlConnection = new SqlConnection( connectionString );
using( sqlConnection ) {
BusinessObject myBusinessObject = new BusinessObject( sqlConnection );
// do stuff with the business object
...
}

Таким чином, видно і очевидно, що я євикористовуючи ресурс, який потрібно належним чином очистити. Однак це призводить до багато повторюваних зусиль. Я спробував створити підключення Sql всередині бізнес-об'єкта та реалізувати IDisposable на нього. Я закрив би з'єднання в методі Dispose ().

using( BusinessObject myBusinessObject = new BusinessObject() ) {
// do stuff with myBusinessObject
...
}

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

Як ви, хлопці, зробите це?

Відповіді:

Бізнес-об'єкти повинні бути обгрунтованими (абоповністю) німий щодо бази даних. Вам слід реалізувати який-небудь об'єкт доступу до рівня доступу (репозиторій або контекст даних), який вміє зберігати бізнес-об'єкти в базі даних і зберігати там логіку з'єднання, а не створювати код у кожному з ваших бізнес-об'єктів. Ваш репозиторій або контекст буде одноразовим, щоб він міг очистити себе. Пропозиція @Marc про те, що ви дотримуєтесь принципу "Одиниці роботи", є хорошим.

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

Добре, спочатку я залишаю з'єднання з сховищем.

По-друге, я б не підтримував підключення зв'язкунавколо об'єкта - я використовую його лише для одиниці роботи (тобто єдиного методу). Швидше за все (через злиття) ви отримаєте однакове фізичне з'єднання в будь-якому випадку. Система вже давно працює над такими ситуаціями, тому вам не потрібно.

Більш складною справою є операції, де TransactionScope набагато простіше, ніж проходження об'єкта db-transaction.

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