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

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

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