Когда я должен избавиться от контекста данных

В настоящее время я пишу уровень доступа к данным для приложения. Уровень доступа широко использует классы linq для возврата данных. В настоящее время, чтобы отразить данные обратно в базу данных, я добавил элемент контекста личных данных и общедоступный метод сохранения. Код выглядит примерно так:

private DataContext myDb;
public static MyClass GetMyClassById(int id)
{
    DataContext db = new DataContext();
    MyClass result = (from item in db.MyClasss
                      where item.id == id
                      select item).Single();
    result.myDb = db;
    return result;
}

public void Save()
{
    db.SubmitChanges();
}

Это грубое по сравнению с упрощением, но оно дает общую идею. Есть ли лучший способ справиться с подобным шаблоном? Должен ли я создавать экземпляр нового контекста данных каждый раз, когда я хочу посетить db?

Ответ 1

На самом деле это не имеет большого значения. Я спросил у Мэтта Уоррена от LINQ to SQL команду об этом некоторое время назад, и вот ответ:

Есть несколько причин, по которым мы реализовали IDisposable:

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

Логика, которая автоматически закрывается соединение DataContext может быть обманывает, оставляя соединение открытый. DataContext опирается на код приложения, перечисляющий все результаты запроса с момента получения конец набора результатов запускает подключение к закрытию. Если приложение использует IEnumerable Метод MoveNext вместо foreach в С# или VB, вы можете выйти перечисление преждевременно. Если ваш приложение испытывает проблемы с соединения не закрываются, и вы подозревать автоматическое закрытие не работает, вы можете использовать Dispose как работа вокруг.

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

Ответ 2

Рассматривайте свой ресурс datacontext как ресурс. И правило использования ресурса говорит

"получить ресурс еще возможно, отпустите его, как только его безопасный"

Ответ 3

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

Лично я могу по большей части жить с созданным разработчиком кода DBML, с частичными реализациями классов для моей бизнес-логики и проверки. Я также создаю абстрактно абстрактную конструкцию данных и наследую ее, чтобы позволить мне перехватывать такие вещи, как методы хранимых процедур и табличных функций, которые добавляются непосредственно в контекст данных и применяют там бизнес-логику.

Образец, который я использовал в ASP.NET MVC, заключается в том, чтобы ввести класс factory, который создает соответствующие контексты данных, необходимые для единиц работы. Использование factory позволяет мне легко обрисовать контекст данных с помощью (1) с помощью обертки вокруг существующего класса контекста данных, чтобы он макетировал (издевался над оберткой, поскольку DataContext нелегко макетируется) и (2) создает Fake/Макет контекстов и фабрик для их создания. Возможность создавать их по желанию с помощью factory делает это так, что мне не нужно поддерживать его в течение длительных периодов времени.