销毁 dataContext 与保持其打开以供将来的数据库访问的性能考虑？

发布于 2024-12-05 11:30:51 字数 1425 浏览 2 评论 0原文

我正在使用 LINQ2SQL 来处理 ASP 中的数据库需求。 Net MVC 3 项目。我有一个单独的 model，其中包含在其自己的类中的所有数据库访问权限，如下所示：

 public class OperationsMetricsDB
{

    public IEnumerable<client> GetAllClients()
    {
        OperationsMetricsDataContext db = new OperationsMetricsDataContext();
        var clients = from r in db.clients
                      orderby r.client_name ascending
                      select r;
        return clients;
    }
    public void AddClient(client newClient)
    {
        OperationsMetricsDataContext db = new OperationsMetricsDataContext();

        db.clients.InsertOnSubmit(newClient);
        db.SubmitChanges();

    }

该类中有大约 50 个不同的方法，它们都会创建然后销毁我的 DataContext 的副本代码>.我的理由是，这种方式可以节省内存，因为在我使用连接并释放内存后，它会破坏 DataContext。但是，我有一种感觉，最好使用 dataContext 的一个副本并保持其打开状态，而不是一遍又一遍地处理和重新建立连接。例如，

public class OperationsMetricsDB
{
    OperationsMetricsDataContext db = new OperationsMetricsDataContext();
    public IEnumerable<client> GetAllClients()
    {            
        var clients = from r in db.clients
                      orderby r.client_name ascending
                      select r;
        return clients;
    }
    public void AddClient(client newClient)
    {
        db.clients.InsertOnSubmit(newClient);
        db.SubmitChanges();

    }

这方面的最佳实践是什么？

原文

I'm using LINQ2SQL to handle my database needs in a ASP. Net MVC 3 project. I have a separate model which contains all my database access in its own class as follows:

 public class OperationsMetricsDB
{

    public IEnumerable<client> GetAllClients()
    {
        OperationsMetricsDataContext db = new OperationsMetricsDataContext();
        var clients = from r in db.clients
                      orderby r.client_name ascending
                      select r;
        return clients;
    }
    public void AddClient(client newClient)
    {
        OperationsMetricsDataContext db = new OperationsMetricsDataContext();

        db.clients.InsertOnSubmit(newClient);
        db.SubmitChanges();

    }

I have about 50 different methods in this class which all create and then destroy a copy of my DataContext. My reasoning was that this way would save memory because it would destroy the DataContext after I use the connection and free up that memory. However, I have a feeling that it may be better to use one copy the dataContext and keep it open instead of disposing and reestablishing the connection over and over again. e.g

public class OperationsMetricsDB
{
    OperationsMetricsDataContext db = new OperationsMetricsDataContext();
    public IEnumerable<client> GetAllClients()
    {            
        var clients = from r in db.clients
                      orderby r.client_name ascending
                      select r;
        return clients;
    }
    public void AddClient(client newClient)
    {
        db.clients.InsertOnSubmit(newClient);
        db.SubmitChanges();

    }

What is the best practice on this?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

香草可樂 2024-12-12 11:30:51

为此，我个人将工作单元模式与存储库结合使用。

UnitOfWork 创建并管理 DataContext。然后，它会根据请求将上下文传递到每个存储库。每次调用者想要对数据库执行一组新操作时，他们都会创建一个新的工作单元。

接口看起来像这样：

public interface IUnitOfWork
{
    IRepository<T> GenerateRepository<T>();
    void SaveChanges();
}

public interface IRepository<T> where T : class
{
    public IQueryable<T> Find();
    public T Create(T newItem);
    public T Delete(T item);
    public T Update(T item);
}

确保上下文的生命周期恰好是一个工作单元的长度（比单个操作长，但比应用程序的生命周期短）。

I personally use the Unit of Work pattern in conjunction with Repositories for this.

The UnitOfWork creates and manages the DataContext. It then passes the context to each repository when requested. Each time the caller wants to do a new set of operations with the database, they create a new UnitOfWork.

The interfaces would look something like:

public interface IUnitOfWork
{
    IRepository<T> GenerateRepository<T>();
    void SaveChanges();
}

public interface IRepository<T> where T : class
{
    public IQueryable<T> Find();
    public T Create(T newItem);
    public T Delete(T item);
    public T Update(T item);
}

That ensures that the context's lifespan is exactly one Unit of Work long (which is longer than a single operation but shorter than the lifespan of the application).

回复收藏 0 原文