哪一层应该创建DataContext？
我在决定系统中的哪一层应创建 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
I have a problem to decide which layer in my system should create DataContext. I have read a book, saying that if do not pass the same DataContext object for all the
database updates, it will sometimes get an exception thrown from the DataContext. That's why i initially create new instance of DataContext in business layer, and pass it into data access layer. So that the same datacontext is used for all the updates. But this lead to one design problem, if i wanna change my DAL to Non-LinqToSQL in future, i need to re-write the code in business layer as well. Please give me some advice on this. Thanks.
Example code
'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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于 DataContext 与 LINQ to SQL 紧密耦合，因此您绝对应该在 DAL 中创建它。
看看我对此提供的答案 有些相关的SO问题。它带来了同样的问题，即 DataContext（实体框架中的 ObjectContext）是否应该在多个数据库操作中保持活动状态，或者应该临时创建和处置。
您提到的问题与通过 DataContext 检索的模型对象只能使用相同的 DataContext 实例进行更新。现在，如果原始 DataContext 已被释放，则任何将更新的模型对象附加到新 DataContext 实例的尝试都将失败。
然而，这不一定是一个问题，具体取决于应用程序的体系结构。
例如，如果通过 LINQ to SQL 检索和操作的模型对象在客户端之间来回序列化（例如在 Web 应用程序或 Web 中），服务）比更新的对象永远不会与最初检索的对象相同。在这种情况下，它们可以安全地附加到新的 DataContext。
Being the DataContext tightly coupled to LINQ to SQL, you should definitely create it in the DAL.
Have a look at the answer I provided to this somewhat related SO question. It brings up the same problem of whether the DataContext (ObjectContext in Entity Framework) should be kept alive across multiple database operations, or it should be created and disposed of ad-hoc.
The problems you are referring to are related to the fact that model objects retrieved through a DataContext can only be updated using the same DataContext instance. Now, if the original DataContext has been disposed, any attempt to attach an updated model object to a new DataContext instance will fail.
However this isn't necessarily an issue, depending on your application's architecture.
For example, ff the model objects retrieved and manipulated through LINQ to SQL are being serialized back and forth between a client (like in a web application or a web service) than the updated objects will never be the same as the ones that were originally retrieved. In that case they can safely be attached to a new DataContext.
恕我直言，当业务逻辑层（BLL）需要对某些存储（DB、XML、磁盘等）进行 I/O 时，最好的方法是让数据访问层（DAL）脱离 BLL，因为您可能会更改它，所以您想要所以实际上，BLL不应该有DataContext，而只是与DAL（Interfaces）的契约。
IMHO, when business logic layer (BLL) needs I/O to some store (DB, XML, disk, etc.), best way to have data access layer (DAL) out of BLL, since you may change it, you want to control caching, etc. So actually, BLL should not have DataContext, just a contract with DAL (Interfaces).
与往常一样，这取决于您的具体情况，但作为一个很好的启发，我建议您在位于您的演示文稿和业务逻辑之间的薄立面。这有时称为服务层的应用程序层。
那是哪里，现在——如何。另一个很好的启发是，您应该使用 AOP 来完成任务。我所说的 AOP 并不是指一个庞大的 AOP 专用框架。几乎所有的表示和 Web 服务框架都提供了一些 AOP 功能，使您能够在业务代码执行之前和之后做一些工作，例如 ASP.NET 中的 IHttpModule 和 WCF 中的 IDispatchMessageInspector。之前插入您的框架并创建 DataContext。
如果您需要更改 DAL，则只需更改 DAL 和用于创建/提交 DAL 更改的代码。事实上，AOP 可注入代码也应该放置在 DAL 程序集中，并且如果可能的话，应该在引导例程中进行配置。
As always, it depends on your particular case, but as a good heuristic I would advise you to create/submit/abandon your DataContext (or your ISession if you're using NHibernate, or your ObjectContext if you're using EDM) in the thin facade that lies between your presentation and your business logic. This is sometimes called Application layer of Service layer.
That was where, now -- how. Another good heuristic says that you should use AOP to accomplish the task. And by AOP I don't mean a huge fat AOP-dedicated framework. Almost all presentation and web service frameworks provide some AOP capabilities witch enable you to do some work before and after the business code gets executed, for example IHttpModule in ASP.NET and IDispatchMessageInspector in WCF. Plug into you framework before and created the DataContext.
If you ever need to change your DAL, you will have to change only DAL and the code you used to create/submit your DAL changes. In fact the AOP-injectable code should also be placed in DAL assembly and, if possible, configured in the bootstrapping routine.