Linq到SQL类的生命周期

Question

据我所知，当我新建一个Linq to SQL类时 ，它相当于新建一个SqlConnection对象 。

假设我有一个带有两个方法的对象： Delete()和SubmitChanges() 。 在每个方法中新建Linq to SQL类是否明智，或者是一个保存Linq to SQL类的私有变量 - 由构造函数新建 - 是要走的路？

我想避免的是暂停。

更新：

namespace Madtastic
{
    public class Comment
    {
        private Boolean _isDirty = false;
        private Int32 _id = 0;
        private Int32 _recipeID = 0;
        private String _value = "";
        private Madtastic.User _user = null;

        public Int32 ID
        {
            get
            {
                return this._id;
            }
        }

        public String Value
        {
            get
            {
                return this._value;
            }

            set
            {
                this._isDirty = true;

                this._value = value;
            }
        }

        public Madtastic.User Owner
        {
            get
            {
                return this._user;
            }
        }


        public Comment()
        {
        }


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

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

            if (comment != null)
            {
                this._id = comment.CommentsID;
                this._recipeID = comment.RecipesID;
                this._value = comment.CommentsValue;
                this._user = new User(comment.UsersID);
            }

            mdc.Dispose();
        }


        public void SubmitChanges()
        {
            Madtastic.DataContext mdc = new Madtastic.DataContext();


            var comment = (from c in mdc.Comments
                           where c.CommentsID == this._id
                           select c).FirstOrDefault();

            if (comment != null && this._isDirty)
            {
                comment.CommentsValue = this._value;
            }
            else
            {
                Madtastic.Entities.Comment c = new Madtastic.Entities.Comment();

                c.RecipesID = this._recipeID;
                c.UsersID = this._user.ID;
                c.CommentsValue = this._value;

                mdc.Comments.InsertOnSubmit(c);
            }


            mdc.SubmitChanges();


            mdc.Dispose();
        }


        public void Delete()
        {
            Madtastic.DataContext mdc = new Madtastic.DataContext();

            var comment = (from c in mdc.Comments
                           where c.CommentsID == this._id
                           select c).FirstOrDefault();

            if (comment != null)
            {
                mdc.Comments.DeleteOnSubmit(comment);

                mdc.SubmitChanges();

                this._isDirty = false;
                this._id = 0;
                this._recipeID = 0;
                this._value = "";
                this._user = null;
            }

            mdc.Dispose();
        }
    }
}

修订后的代码（根据Grank的规范）：

namespace Madtastic
{
    public sealed class CommentNew : IDisposable
    {
        private Madtastic.DataContext _mdc;
        private Madtastic.Entities.Comment _comment;
        private Madtastic.User _user;


        public Int32 ID
        {
            get
            {
                return this._comment.CommentsID;
            }
        }

        public String Value
        {
            get
            {
                return this._comment.CommentsValue;
            }

            set
            {
                this._comment.CommentsValue = value;
            }
        }

        public Madtastic.User Owner
        {
            get
            {
                return this._user;
            }
        }


        public void Comment(Int32 commentID)
        {
            this._mdc = new Madtastic.DataContext();

            this._comment = (from c in _mdc.Comments
                             where c.CommentsID == commentID
                             select c).FirstOrDefault();

            if (this._comment == null)
            {
                this._comment = new Madtastic.Entities.Comment();

                this._mdc.Comments.InsertOnSubmit(this._comment);
            }
            else
            {
                this._user = new Madtastic.User(this._comment.User.UsersID);
            }
        }


        public void SubmitChanges()
        {
            this._mdc.SubmitChanges();
        }


        public void Delete()
        {
            this._mdc.Comments.DeleteOnSubmit(this._comment);

            this.SubmitChanges();
        }


        void IDisposable.Dispose()
        {
            this._mdc.Dispose();
        }
    }
}

Answer 1

取决于你所谓的“LINQ-to-SQL类”，以及所讨论的代码是什么样的。
如果您正在谈论DataContext对象，并且您的代码是一个具有较长生命周期的类或您的程序本身，我相信最好在构造函数中初始化它。 它不是真的像创建和/或打开一个新的SqlConnection，它实际上非常聪明地管理它的数据库连接池和并发性和完整性，这样你就不需要考虑它，这是我迄今为止经验中的快乐的一部分。 LINQ到SQL。 我从未见过发生超时问题。
您应该知道的一件事是，跨DataContext范围共享表对象非常困难，如果您可以避免它，则不建议使用它。 Detach（）和Attach（）可能很糟糕。 因此，如果您需要传递表示SQL数据库中表的行的LINQ-to-SQL对象，您应该尝试设计DataContext对象的生命周期，以包含您需要对任何对象执行的所有工作从它出来。
此外，实例化DataContext对象会产生大量开销，并且由它管理很多开销......如果你反复敲击相同的几个表，最好使用相同的DataContext实例，因为它将管理其连接池，并在某些情况下缓存一些事情以提高效率。 但是，建议不要将数据库中的每个表都加载到DataContext中，只加载您需要的表，如果在非常独立的情况下访问的表是非常独立的，您可以考虑将它们分成多个DataContexts，这样就可以了如果周围环境不同，则初始化每个选项时的选项。

Answer 2

现在回顾了您编辑发布的代码示例，我肯定会重构您的类以利用LINQ-to-SQL的内置功能。 （我不会编辑我以前的评论，因为这是一般问题的更好答案）
您的类的字段似乎是数据库中“注释”表上列的非常直接的映射。 因此，您不需要在此课程中手动执行大部分操作。 大多数功能都可以通过拥有Madtastic.Entities.Comment类型的私有成员来处理（如果你必须维护这个类与项目其余部分的交互方式，那么只需将属性映射到它的属性）。 然后你的构造函数可以初始化一个私有成员Madtastic.DataContext并将你的私有成员Madtastic.Entities.Comment设置为LINQ查询的结果。 如果注释为null，则创建一个新注释并在DataContext上调用InsertOnSubmit。 （但提交更改没有意义，因为您还没有为此新对象设置任何值）
在SubmitChanges中，您所要做的就是在DataContext上调用SubmitChanges。 它自己跟踪数据是否需要更新，如果没有，它将不会访问数据库，因此您不需要_isDirty。
在Delete（）中，您所要做的就是在DataContext上调用DeleteOnSubmit。
实际上，您可能会在一点点回顾中发现您根本不需要Madtastic.Comment类，而Madtastic.Entities.Comment LINQ-to-SQL类可以直接作为您的数据访问层。 似乎唯一的实际差异是带有commentID的构造函数，以及Entities.Comment有一个UsersID属性，其中Madtastic.Comment类有一个完整的User。 （但是，如果User也是数据库中的表，并且UsersID是其主键的外键，您会发现LINQ-to-SQL已在Entities.Comment对象上创建了一个可以直接访问的User对象评论。用户）
如果您发现可以完全消除此类，则可能意味着您可以通过将其扩展到项目中使用Comment的方法来进一步优化DataContext的生命周期。

编辑发布以下示例重构代码（对于任何错误道歉，因为我在几秒钟内在记事本中键入它而不是打开visual studio，我无论如何都不会为你的项目获得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。

Answer 3

我假设你的意思是为DataContext类保存一个值？ 就个人而言，我的偏好是默认为IDisposable（DataContext类所有）的“using”子句。 在构造函数中实例化并将DataContext保存在私有变量中会使这变得不可能。 所以对我来说，我将实例化放在方法中，但更具体地说，我将实例化放在using子句中，以便保证适当的处理。

Answer 4

我当前的一个项目使用Linq to SQL，我们将datacontext作为对象内部的私有字段。 这样做在大多数情况下并不麻烦，如果我在构造函数中传入datacontext，则允许将来进行模拟，并且看起来比打开多个datacontexts更简洁。 与Jacob上面提到的类似，我们正在实现IDisposable以确保在不再需要对象时可以可靠地关闭datacontext。

Answer 5

默认情况下，SqlConnections是池化的。 你应该新建他们以证明合理的成本！

DataContexts制作起来很便宜（在第一次之后）。 你应该新建他们以证明第一次新的成本！