Продолжительность жизни класса Linq to SQL

Я предполагаю, что вы имеете в виду сохранение значения для класса DataContext? Лично я предпочитаю по умолчанию использовать предложение using для всего, что является IDisposable (каковыми являются классы DataContext). Создание экземпляра в конструкторе и сохранение DataContext в частной переменной сделало бы это невозможным. Итак, для меня я бы поместил создание экземпляра в методы, но, более конкретно, я бы поместил создание экземпляра в предложение using, чтобы обеспечить правильное удаление.

Зависит от того, что вы называете «классом LINQ-to-SQL», и как выглядит рассматриваемый код. Если вы говорите об объекте DataContext, а ваш код - это класс с длительным сроком службы или сама ваша программа, я считаю, что лучше всего инициализировать его в конструкторе. На самом деле это не похоже на создание и / или открытие нового SqlConnection, на самом деле он очень умно управляет своим пулом подключений к базе данных, параллелизмом и целостностью, так что вам не нужно думать об этом, это часть радости в моем опыте работы с LINQ-to-SQL. Я никогда не видел, чтобы возникала проблема с тайм-аутом. Вы должны знать одну вещь: очень сложно совместно использовать объекты таблиц в области DataContext, и это действительно не рекомендуется, если вы можете этого избежать. Detach () и Attach () могут быть неприятными. Поэтому, если вам нужно передать объект LINQ-to-SQL, который представляет строку в таблице в вашей базе данных SQL, вы должны попытаться спроектировать жизненный цикл объекта DataContext, чтобы охватить всю работу, которую вам нужно выполнить с любым объектом. что выходит из этого.
Кроме того, существует много накладных расходов, связанных с созданием экземпляра объекта DataContext, и много накладных расходов, которыми он управляет ... Если вы снова и снова нажимаете одни и те же таблицы, было бы лучше использовать один и тот же экземпляр DataContext , поскольку он будет управлять своим пулом соединений и в некоторых случаях кэшировать некоторые вещи для повышения эффективности. Однако рекомендуется не загружать все таблицы в вашей базе данных в ваш DataContext, а только те, которые вам нужны, и если таблицы, к которым осуществляется доступ, очень разные в очень разных обстоятельствах, вы можете рассмотреть возможность разделения их на несколько DataContexts, что даст вам некоторые параметры при инициализации каждого из них, если окружающие их обстоятельства различны.

Один из моих текущих проектов использует Linq to SQL, где мы храним текст данных как частное поле внутри объекта. По большей части это не было проблемой, позволяет в будущем издеваться, если я передаю текст данных в конструктор, и просто кажется более чистым, чем открытие нескольких контекстов данных. Подобно тому, что упомянул Джейкоб выше, мы реализуем IDisposable, чтобы убедиться, что контекст данных может быть надежно закрыт, когда объект больше не нужен.

По умолчанию SqlConnections объединяются в пул. Вы должны обновить их кучу, чтобы оправдать затраты на объединение!

DataContexts дешево создавать (после первого). Вы должны обновить их кучу, чтобы оправдать эти первые затраты на обновление!

Теперь, просмотрев образец кода, который вы отредактировали для публикации, я определенно реорганизовал бы ваш класс, чтобы воспользоваться преимуществами встроенных функций LINQ-to-SQL. (Я не буду редактировать свой предыдущий комментарий, потому что это лучший ответ на общий вопрос)
Поля вашего класса кажутся довольно прямым отображением столбцов в таблице комментариев в базе данных. Поэтому вам не нужно делать большую часть того, что вы делаете вручную в этом классе. Большую часть функциональности можно реализовать, просто имея закрытый член типа Madtastic.Entities.Comment (и просто сопоставляя свои свойства с его свойствами, если вам нужно поддерживать взаимодействие этого класса с остальной частью проекта). Затем ваш конструктор может просто инициализировать закрытый член Madtastic.DataContext и установить закрытый член Madtastic.Entities.Comment на результат LINQ-запроса на нем. Если комментарий пустой, создайте новый и вызовите InsertOnSubmit в DataContext. (но пока не имеет смысла отправлять изменения, потому что вы все равно не установили никаких значений для этого нового объекта)
В вашем SubmitChanges все, что вам нужно сделать, это вызвать SubmitChanges в DataContext. Он самостоятельно отслеживает, нужно ли обновлять данные, в противном случае он не попадет в базу данных, поэтому вам не нужен _isDirty.
В вашем Delete () все, что вам нужно сделать, это вызвать DeleteOnSubmit в DataContext.
Фактически, сделав небольшой обзор, вы можете обнаружить, что вам вообще не нужен класс Madtastic.Comment, а класс Madtastic.Entities.Comment LINQ-to-SQL может действовать непосредственно как ваш уровень доступа к данным. Похоже, что единственными практическими отличиями являются конструктор, который принимает commentID, и тот факт, что Entities.Comment имеет свойство UsersID, где ваш класс Madtastic.Comment имеет целого User. (Однако, если User также является таблицей в базе данных, а UsersID является внешним ключом для его первичного ключа, вы обнаружите, что LINQ-to-SQL создал объект User в объекте Entities.Comment, к которому вы можете получить доступ напрямую. с комм. пользователя)
Если вы обнаружите, что можете полностью исключить этот класс, это может означать, что вы можете дополнительно оптимизировать жизненный цикл своего DataContext, добавив его к методам в вашем проекте, которые используют комментарий.

Отредактировано для публикации следующего примера реорганизованного кода (извиняюсь за любые ошибки, так как я набрал его в блокноте через пару секунд, а не открывал визуальную студию, и я бы все равно не получил intellisense для вашего проекта):

namespace Madtastic
{
    public class Comment
    {
        private Madtastic.DataContext mdc;
        private Madtastic.Entities.Comment comment;

        public Int32 ID
        {
            get
            {
                return comment.CommentsID;
            }
        }

        public Madtastic.User Owner
        {
            get
            {
                return comment.User;
            }
        }

        public Comment(Int32 commentID)
        {            
            mdc = new Madtastic.DataContext();

            comment = (from c in mdc.Comments
                           where c.CommentsID == commentID
                           select c).FirstOrDefault();

            if (comment == null)
            {
                comment = new Madtastic.Entities.Comment();
            mdc.Comments.InsertOnSubmit(comment);
            }

        }

        public void SubmitChanges()
        {

            mdc.SubmitChanges();

        }


        public void Delete()
        {
            mdc.Comments.DeleteOnSubmit(comment);
            SubmitChanges();
        }
    }
}

Вы, вероятно, также захотите реализовать IDisposable / using, как предлагали некоторые люди.