Инкапсулировать соединение с базой данных в бизнес-объекты или нет?

Question

Мне обычно нравится создавать соединение с базой данных самостоятельно и управлять его временем жизни вручную с помощью `using {} '. Например:

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
    ...
}

Проблема, с которой я сталкиваюсь, заключается в том, что может быть не так очевидно, что бизнес-объект необходимо утилизировать, если вы не видите его в использовании.

Как бы вы, ребята, сделали это?

Answer 1

Бизнес-объекты должны быть достаточно (или полностью) тупыми по отношению к базе данных. Вы должны реализовать некоторый объект уровня доступа (хранилище или контекст данных), который знает, как сохранить ваши бизнес-объекты в базе данных и сохранить там логику соединения, а не помещать код в каждый из ваших бизнес-объектов. Ваш репозиторий или контекст был бы одноразовым, чтобы он мог убирать за собой. Предложение Марка о том, что вы следуете шаблону «Единица работы», является хорошим.

Возможно, вы захотите взглянуть на LINQtoSQL, nHibernate, Subsonic и т. Д., Чтобы использовать их или хотя бы узнать, как структурировать хороший слой данных, если вы настаиваете на написании своего собственного. Исходя из личного опыта, я могу вам сказать, что использовать существующую технологию гораздо проще, чем писать и поддерживать свою собственную.

Answer 2

Ну, во-первых, я бы оставил подключения к хранилищу.

Во-вторых, я бы не стал держать соединение вокруг объекта - я бы использовал его только для единицы работы (то есть для одного метода). Скорее всего, (из-за объединения) вы все равно получите то же физическое соединение. Система уже проходит долгий путь для обработки таких вещей, так что вам не нужно.

Более сложный случай - транзакции, где TransactionScope намного проще, чем передавать объект db-транзакции.

Answer 3

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