Какой слой должен создать DataContext? - PullRequest
Новая
       12

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

1 голос
/ 22 марта 2010

У меня есть проблема, чтобы решить, какой слой в моей системе должен создать 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

Ответы [ 3 ]

2 голосов
/ 22 марта 2010

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

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

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

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

1 голос
/ 22 марта 2010

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

0 голосов
/ 22 марта 2010

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

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

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

...