我对 DataContext 的生命周期进行了一些研究,试图弄清楚什么是最好的做事方式。
考虑到我想在 Web 应用程序中重复使用我的 DAL,我决定采用 DataContext Per Business Object Request 方法。
我的想法是从 dbml 文件扩展我的 L2S 实体以检索数据库的信息,为每个请求创建一个单独的上下文,例如
public partial class AnEntity
{
public IEnumerable<RelatedEntity> GetRelatedEntities()
{
using (var dc = new MyDataContext())
{
return dc.RelatedEntities.Where(r => r.EntityID == this.ID);
}
}
}
就返回实体而言...此时我需要返回 POCO 还是只返回从查询返回的业务对象就可以了?我知道如果我尝试访问返回实体的属性(在处理 DataContext 之后),它会失败。然而,这就是我决定实现这些类型方法的原因,例如
代替:
AnEntity entity = null;
using (var repo = new EntityRepo())
{
entity = repo.GetEntity(12345);
}
var related = entity.RelatedEntities; // this would cause an exception
理论上我应该能够做到:
AnEntity entity = null;
using (var repo = new EntityRepo())
{
entity = repo.GetEntity(12345);
}
var related = entity.GetRelatedEntities();
鉴于我的特定应用程序的情况(需要在 Windows 服务和 Web 应用程序中工作)我想知道这是否是一种合理的方法,是否存在明显的缺陷以及是否有更好的方法来解决我的问题我正在尝试做。
谢谢。
最佳答案
一般来说,只要您不使用多个线程调用单个 DataContext 对象,就应该没问题。换句话说,每个线程使用一个 DataContext 对象,并且不在不同的 DataContext 对象之间共享数据或状态。
剩下的多线程问题与concurrency有关在数据库中,而不是线程操作。
除了这些警告之外,您的方法似乎很合理。您可以使用部分类来实现您的业务方法,也可以在 Linq to SQL 类和您的存储库之间添加一个业务层。
关于c# - Linq to SQL - 我应该如何管理数据库请求?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1925011/