我的问题分为几个部分，可能会很长时间，很抱歉。
我正在使用LINQ将数据传递给Silverlight客户端。
第1部分：连接池＆amp;优化： 我想知道如何确保LINQ只建立一个与数据库的连接，并遵循连接池。过去，我曾经将连接池属性放在SQL连接字符串本身中。所以，如果我把这个设置文件，当我在DBML文件中添加表时设置连接字符串的地方，LINQ会尊重它 LINQ（DBML）构成了我的数据访问层的核心。我编写的类具有基本上是LINQ查询的方法。 我在代码中的“using”块中使用DataContext对象，我处理数据相关的部分。 这是LINQ可能使用多个连接的原因吗？如果我将DataContext作为类级变量，那么这只能确保一个连接吗？
第2部分：优化 在不久的将来，ADO.Net时代，我曾经编写存储过程，通过DataReader执行它，然后遍历DataReader，填充我的Model类的多个对象，并传递该集合以绑定到DataGrid。 在LINQ时代，我或多或少地创建了一个对象集合。但是我自己执行直接的LINQ语句。 我可以猜测SQL存储过程会给我更快的性能，但是如果我使用LINQ执行存储过程，它会像过去一样快，是否是正确的方法？
答案 0 :(得分：7)
第2部分：优化不是那么遥远 过去，ADO.Net天，我曾经写过 存储过程，通过执行它 DataReader然后循环遍历 DataReader，填充我的多个对象 模型类并传递给它 用于绑定到DataGrid的集合。在 LINQ天，我或多或少都一样 远远创建一个对象集合 被关注到。但我直接执行 LINQ语句本身。我能猜到 那个SQL存储过程会给出 我的表现更快，但是
基本上，过去你有一些轻微的妄想。存储过程现在已经超过10年没有（！）性能提升。它在文档中清楚地说明了。 SQL执行速度与非存储过程一样快，查询计划被缓存并重用于两者。
如果SP避免往返（即从客户端向服务器发送多批请求），那么SP只会很好（如：节省时间）。然后节省的不是因为它们是传统的程序，而是由于往返旅行需要时间。 遗憾的是，许多程序员仍然有妄想，因为他们是从其他人那里得到的...... 10年前，当存储过程具有内在优势时。现在这是SQL Server 6.5时间 - 从7.0开始这是历史。http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
基本上你处理了丢失的开发时间和许多无用的代码......最可能没有可衡量的优势。
你不这样做。基本上不要试图变得更聪明而不是对你有好处。多个连接有什么问题？如果他们感觉到了什么？第1部分：连接池＆amp; 优化：我想知道我该怎么做 确保LINQ只建立一个 连接到数据库，也遵循 连接池。
对于池，yu应该（sql server）不必在连接字符串中正常放置任何内容。是的，LINQ不会神奇地绕过连接字符串中定义的连接池。请参阅，LINQ没有与数据库交谈 - 它使用ADO.NET，而ADO.NET并没有神奇地改变行为，因为一些更高级别的ORM正在使用它而不是你。连接字符串具有池条目，ADO.NET仍然可以看到它们并跟随它们。
现在，从服务器池只有一个数据库连接是一回事：STUPID。它一次限制一个事务，一旦负载变高就完全破坏性能（即需要同时处理多个请求）。
我在中使用DataContext对象 在我的代码中“使用”块 处理数据相关部分。这是 LINQ可能正在使用的原因 多重连接？如果我有 DataContext作为类级变量， 这会确保只有一个连接吗？
啊 - 取决于。它可能有意义，它可能没有。你知道，在你认为你遇到问题之前，特别是考虑到你在这里提供的信息量很大（即没有），做一件唯一明智的事情：抓住一个分析器并测量你是否有一个。打开/关闭连接100次或1000次最有可能甚至不会出现在探查器上。没有问题=无理由修复。
那就是说，我不喜欢每个方法连接开放 - 它通常显示一个糟糕的类设计。连接应该在一个工作单元中重用。