Какой слой должен создать DataContext?

Question

У меня проблема решить, какой слой в моей системе должен создать DataContext. Я прочитал книгу, говоря, что если не передавать один и тот же объект DataContext для всех обновлений базы данных , он иногда получает исключение, выведенное из DataContext. Вот почему я изначально создаю новый экземпляр DataContext на бизнес-уровне и передаю его на уровень доступа к данным. Чтобы один и тот же файл данных использовался для всех обновлений. Но это приводит к одной проблеме проектирования, если я хочу изменить свой DAL на Non-LinqToSQL в будущем, мне также нужно переписать код на бизнес-уровне. Пожалуйста, дайте мне несколько советов по этому поводу. Благодарю.

Пример кода

'Business Layer 
Public Sub SaveData(name As String) 
Using ts AS New TransactionScope() 
Using db As New MyDataContext() 
    DAL.Insert(db,name) 
    DAL.Insert(db,name) 
End Using 
ts.Complete() 
End Using 
End Sub 

'Data Access Layer 
Public Sub Insert(db as MyDataContext,name As string) 
    db.TableAInsert(name) 
End Sub 

Answer 1

ИМХО, когда бизнес-логики (BLL) необходим ввод/вывод в какой-то магазин (DB, XML, диск и т.д.), лучший способ иметь уровень доступа к данным (DAL) из BLL, так как вы можете изменить его, вы хотите контролировать кеширование и т. д. Так что на самом деле BLL не должен иметь DataContext, а только контракт с DAL (интерфейсы).

Answer 2

Будучи DataContext, тесно связанным с LINQ to SQL, вы должны обязательно создать его в DAL.

Посмотрите на ответ, который я предоставил на это somewhat related SO question. Возникает та же проблема: следует ли поддерживать DataContext (ObjectContext в Entity Framework) в нескольких операциях с базами данных или создавать и удалять ad-hoc.

Проблемы, о которых вы говорите, связаны с тем, что model objects retrieved through a DataContext can only be updated using the same DataContext instance. Теперь, если исходный DataContext был удален, любая попытка присоединения обновленного объекта модели к новому экземпляру DataContext завершится с ошибкой.

Однако это не обязательно проблема, в зависимости от архитектуры вашего приложения.
Например, если объекты модели, полученные и обработанные через LINQ to SQL, сериализуются между клиентом (например, в веб-приложении или веб-службе), чем обновленные объекты никогда не будут такими же, как те, которые изначально были извлекаться. В этом случае их можно безопасно привязать к новому DataContext.

Answer 3

Как всегда, это зависит от вашего конкретного случая, но в качестве хорошей эвристики я бы посоветовал создать/отправить/оставить свой DataContext (или ваш ISession, если вы используете NHibernate или ваш ObjectContext, если используете EDM) в тонком фасаде, который лежит между вашей презентацией и вашей бизнес-логикой. Это иногда называют прикладным уровнем уровня сервиса.

Это было, сейчас - как. Другая хорошая эвристика говорит, что вы должны использовать АОП для выполнения задачи. И AOP я не имею в виду огромную AOP-выделенную инфраструктуру. Почти все структуры представления и веб-службы предоставляют некоторые возможности AOP, позволяющие вам выполнять некоторую работу до и после выполнения бизнес-кода, например IHttpModule в ASP.NET и IDispatchMessageInspector в WCF. Вставьте в свою инфраструктуру раньше и создайте DataContext.

Если вам когда-либо понадобится изменить свой DAL, вам придется изменить только DAL и код, который вы использовали для создания/отправки изменений DAL. Фактически, код AOP-инъекции также должен быть помещен в узел DAL и, если возможно, настроен в подпрограмме начальной загрузки.