方法 - 优化LINQ以提高性能

Question

我的问题分为几个部分,可能会很长,对此感到抱歉.

我正在使用LINQ将数据传递给Silverlight客户端.

第1部分:连接池和优化:我想知道如何确保LINQ只建立一个与数据库的连接,并遵循连接池.过去,我曾经将连接池属性放在SQL连接字符串本身中.所以,如果我把这个设置文件放在我在DBML文件中添加表时设置连接字符串的地方,那么LINQ会认为LINQ(DBML)是我数据访问层的核心.我编写的类具有基本上是LINQ查询的方法.我在代码中的"using"块中使用DataContext对象,我处理数据相关的部分.这是LINQ可能使用多个连接的原因吗？如果我将DataContext作为类级别变量,那么这只能确保一个连接吗？

第2部分:优化在不久的将来,ADO.Net时代,我曾经编写存储过程,通过DataReader执行它,然后遍历DataReader,填充我的Model类的多个对象,并传递该集合以进行绑定数据网格.在LINQ时代,我或多或少地创建了一个对象集合.但是我自己执行直接的LINQ语句.我可以猜测SQL存储过程会给我带来更快的性能,但如果我使用LINQ执行存储过程,它会像过去那样快,它是一种正确的方法吗？

Answer 1

噢......这么多坏习惯.

第2部分:优化在不久的将来,ADO.Net时代,我曾经编写存储过程,通过DataReader执行它,然后遍历DataReader,填充我的Model类的多个对象,并传递该集合以进行绑定数据网格.在LINQ时代,我或多或少地创建了一个对象集合.但是我自己执行直接的LINQ语句.我猜测SQL存储过程会给我更快的性能,但是

基本上,在过去你有一些轻微的妄想.存储过程现在已经超过10年没有(!)性能提升.它在文档中清楚地说明了.SQL执行与非存储过程一样快,查询计划被缓存并重用于两者.

如果它们避免往返(即从客户端向服务器发送多批请求),则SP仅是好的(如:节省时间).然后节省的不是因为它们是存储程序,而是由于往返行程需要时间.

可悲的是,许多程序员仍然有妄想,因为他们从其他人那里得到它们...... 10年前,当存储过程具有内在优势时.现在这是SQL Server 6.5时间 - 从7.0开始这是历史.

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

基本上你处理了丢失的开发时间和许多无用的代码....最可能没有可衡量的优势.

第1部分:连接池和优化:我想知道如何确保LINQ只建立一个与数据库的连接,并遵循连接池.

你不.基本上不要试图变得更聪明而不是对你有好处.多个连接有什么问题？如果他们感觉有什么问题？

对于池,yu应该(sql server)不必在连接字符串中正常放置任何内容.是的,LINQ不会神奇地绕过连接字符串中定义的连接池.请参阅,LINQ没有与数据库交谈 - 它使用ADO.NET,而ADO.NET并没有神奇地改变行为,因为一些更高级别的ORM正在使用它而不是你.连接字符串具有池条目,ADO.NET仍然可以看到它们并跟随它们.

现在,从服务器池只有一个数据库连接是一回事:STUPID.它一次限制一个事务,并且一旦负载变高就完全破坏性能(即需要同时处理多个请求).

我在代码中的"using"块中使用DataContext对象,我处理数据相关的部分.这是LINQ可能使用多个连接的原因吗？如果我将DataContext作为类级别变量,那么这只能确保一个连接吗？

啊 - 取决于.它可能有意义,它可能没有.你知道,在你认为你有问题之前,特别是考虑到你在这里提供的信息量很大(即没有),做一件唯一明智的事情:抓住一个探查器并测量你是否有一个.打开/关闭连接100次或1000次最有可能甚至不会出现在探查器上.没有问题=无理由修复某些问题.

也就是说,我不喜欢每个方法连接打开 - 它通常显示一个糟糕的类设计.连接应该在一个工作单元中重用.