LinqToSql объявляют и инстанцируют лучшей практики DataContext?

Как Король сказал M, datacontext предназначается, чтобы инстанцироваться, использоваться и располагаться для каждой логической транзакции. Шаблоны как это иногда называют "единицей работы".

Наиболее распространенный способ (что я знаю о), чтобы сделать это должно инстанцировать Вашего datacontext в блоке использования. Я не использовал VB в некоторое время, но он должен выглядеть примерно так:

Using dc As New MyDataContext()
   user = (From u in dc.Users Where u.ID = UserID).Single()
End Using

Это не только укрепляет вид транзакции/единицы работы (через физическую форму кода), но это гарантирует, чтобы вызов Расположил () на Вашем datacontext когда концы блока.

Посмотрите эту страницу MSDN:

В целом экземпляр DataContext разработан для длительности одну "единицу работы" однако приложение определяет тот термин. DataContext является легким и не является дорогим для создания. Типичный LINQ к приложению SQL создает экземпляры DataContext в объеме метода или как член недолгих классов, которые представляют логический набор связанных операций базы данных.

Я думаю, возможно, что настоящая проблема - это User вероятно, не правильное место для вызова члена экземпляра GetUser.

Существует несколько различных путей, которыми Вы могли пойти об этом, которое будет хорошей практикой, я думаю. Сначала Вы могли использовать шаблон Репозитория, где Вы запрашиваете Репозиторий для объекта, он выходит в базу данных, получает объект - возможно, отсоединение его от контекста данных или имения в наличии контекста данных в зависимости от реализации Репозитория - и возвращает его Вам. Методы фабрики для Ваших объектов были бы на Репозитории, не самих объектах. Вы, вероятно, использовали бы отражение и дженерики для уменьшения количества методов, необходимо реализовать и сохранить код DRY.

Другой путь и способ, которым LINQtoSQL был предназначен, чтобы использоваться исходно, по моему скромному мнению, состоят в том, чтобы создать контекст данных для каждого набора операций базы данных, которые Вы намереваетесь выполнить. В этом создание контекста данных происходит вне объекта также, обычно в классе, который использует объекты, не в слое данных вообще. Вы могли также добавить, что методы к контексту данных - делают Ваш фактический краткий обзор контекста данных и наследовались ему - использование отражения снова, для выполнения некоторых общих функций извлечения так, чтобы Вы не повторяли их. Необходимо было бы, вероятно, использовать шаблон базы данных как ActiveRecords, где идентификационные столбцы всегда имеют то же имя для создания этой работы.

С другой стороны, Вы могли посмотреть на использование nHibernate или ActiveRecord Замка вместо того, чтобы копировать любое из вышеупомянутого в Вашем собственном решении.

Может быть легче, если Вы оставляете Пользовательский класс в покое и позволяете дескриптор IDE, это - создание.

Часто я предпочитаю иметь отдельный дескриптор класса поиск данных. Скажем, Вы называете это, UserDataProvider и все вызовы для получения Пользовательского экземпляра в конечном счете проходят этот класс.

Конструктор UserDataProvider мог инстанцировать глобального экземпляра объекта контекста данных для повторного использования. Это выглядело бы примерно так (в C# и непротестированном коде, так терпите меня):

public class UserDataProvider 
{
    private UserDataContext _data = null;

    public UserDataProvider()
    {
        _data = new UserDataContext();
    }

    public User GetUser(int userID)
    {
        return _data.Users.FirstOrDefault(u => u.UserID == userID);
    }
}

С другой стороны, Вы могли бы поместить инициализацию в свойство и доступ что свойство для использования контекста данных.

public class UserDataProvider 
{
    private UserDataContext _dataContext;

    private UserDataContext DataContext 
    {
        get
        {
            if (_data == null)
                _data = new UserDataContext();

            return _data;
        }
    }

    public User GetUser(int userID)
    {
        return DataContext.Users.FirstOrDefault(u => u.UserID == userID);
    }
}