Производительность рассмотрения уничтожения dataContext против сохранения его для будущего доступа к БД? - PullRequest
Новая
       13

Производительность рассмотрения уничтожения dataContext против сохранения его для будущего доступа к БД?

4 голосов
/ 20 сентября 2011

Я использую 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();

    }

Какая лучшая практика в этом отношении?

Ответы [ 3 ]

1 голос
/ 21 сентября 2011

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

Но я бы не создавал новый экземпляр контекста для каждого отдельного вызова метода вашего класса данных.

Я предпочитаю использовать его в единицах стиля работы. В веб-приложении обработка http-запроса может рассматриваться как единица работы.

Поэтому я советую создать один экземпляр datacontext для времени жизни по запросу http и затем утилизировать его.

1 голос
/ 20 сентября 2011

Для этого я лично использую шаблон единиц работы вместе с репозиториями.

UnitOfWork создает и управляет DataContext.Затем он передает контекст в каждое хранилище по запросу.Каждый раз, когда абонент хочет выполнить новый набор операций с базой данных, он создает новый UnitOfWork.

Интерфейсы будут выглядеть примерно так: 

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);
}

Это гарантирует, что срок службы контекстаровно одна единица работы (которая длиннее одной операции, но короче срока службы приложения).

0 голосов
/ 21 сентября 2011

Один контекст на запрос обычно подходит для большинства приложений.

http://blogs.microsoft.co.il/blogs/gilf/archive/2010/05/18/how-to-manage-objectcontext-per-request-in-asp-net.aspx

...