.net 连接到DB的成本是否仍然更高？

我是ASP.NET的新手，正在构建第二个实时Web应用程序

一年前我在学习ASP.NET时，有人告诉我“连接和从数据库中获取数据的成本更高，因此尽可能减少连接并有效地重新使用检索到的数据”。理由如下：

首先需要建立到DB服务器的连接

与IIS相比，DB服务器上的并发连接更少

使用断开连接的体系结构，以便可以很快关闭连接（当然，也有其他灵活性） 等等等等

当我的研究扩大时，我学到了存储从数据库中检索到的数据的其他方法，即跨回发。但现在，我一个接一个地了解到，它们比连接到DB的成本更高。像

会话变量：内存大小气泡与用户数

视图状态：加密和旅行的过程使其成本更高

应用程序变量：并非在所有情况下都很有用

Cache：（我知道，但到现在还没用过）

同样是最近，我被反复建议不要将检索到的表存储在会话、视图状态等中，而是连接到DB并在每次回发时重新获取它

从基于SQL Server的会话状态管理的角度来看，框架本身使用DB来存储会话我觉得，我应该放弃对数据库连接的最初学习和认知。

你怎么说

欢迎提供任何其他建议/提示

---

谢谢

一般来说，您所说的是正确的，但是连接池消除了大量建立连接的开销

使用连接池时，您有一个连接集合，在向数据库发出请求时使用这些连接。然后，这些连接被回收用于后续用途。我在解释这一点上做得很差，但维基百科总是有一些好的信息让你开始

如果你正在寻找一个银弹，比如总是使用xxx，不幸的是没有。您需要评估每个场景，并在其中做出决定

例如，如果与数据库服务器的连接速度较慢，则可能需要缓存检索到的数据，以尽量减少对数据库的调用次数

另一方面，如果您的系统资源有限，那么频繁调用数据库可能是一个有效的选择

---

您必须为您开发的每个系统评估这些情况，以最大限度地利用软件，但如果架构正确，通常很容易使系统适应您遇到的任何约束。

连接池可以极大地限制建立数据库连接的成本。连接池是一种ADO.NET（我认为）技术，只要连接字符串相同，它基本上会恢复数据库连接。我也会小心缓存数据，除非您知道缓存的数据是相当静态的

因此，总而言之，我想说的是不要担心建立到数据库的连接的成本。大多数N层、断开连接的应用程序频繁地连接到数据库。我想你不必为此担心

---

Randy

连接池现在减少了开销

---

我发现往返会降低性能，这通常是因为ORMs:-）

与本地RAM中的任何东西相比，DB连接通常会很慢。是的，在RAM中存储东西会导致内存使用率随着并发用户数量的增加而膨胀……那么呢？这就是跨多台机器扩展的目的。一切都是权衡。你需要看看你想要完成什么，然后选择交易什么。

使用连接池是个好主意。当您必须从数据库获取数据时，JSON是一种很好的方法。我们应该尽量避免会话和视图状态，因为它们会多次降低应用程序性能。

我同意前面的许多评论。连接池意味着如果一个数据库连接位于池中且可用，则不需要打开新的数据库连接

话虽如此，但要小心重复访问数据库，特别是对于可以缓存的主列表类型的数据。用于数据库访问的面向对象代码因太多的数据库活动而臭名昭著，其中许多活动只需稍加规划即可避免。使用ASP.NET的应用程序缓存来存储不经常更改的静态数据（如果经常更改，则刷新并重新加载缓存）

我不喜欢会话变量，因为它们类似于全局变量，并且会导致编码过于草率。它们也不适合REST、Azure等采用的无状态编程模型，只有我的2美分

小心过载Viewstate，但如果您将其保持较小，我看不出有任何问题

---

-Krip

内存使用率甚至不必随着并发用户的增加而增加，这就是缓存类或更好的memcached的用途。通过性能和数据库连接重新标记，以便让一些观看这些标记的人加入讨论。