DAAB，使用数据库实例的最佳方法是
伙计们，我将使用 Enterprise Library (4.1)，尤其是 DAAB。 我有以下问题：
最好的方法是什么以及为什么：
每次当我需要运行时 DbCommand 我创建数据库实例 使用 DatabaseFactory.CreateDatabase();
我有一个带有实例的基类 数据库（使用相同的 CreateDatabase() 静态方法）和 像公共财产之类的东西 返回实例化数据库。
创建数据库类的实例如何“重”或快/慢？ 如果我每次需要 DbCommand 时都这样做怎么办？
谢谢。
Guys, I am going to use Enterprise Library (4.1) and especially DAAB. Here is I have questions:
What is the best approach and why:
Every time when I need to run a
DbCommand I create Database instance
using
DatabaseFactory.CreateDatabase();I have a base class with instanced
Database (using the same
CreateDatabase() static method) and
something like public property which
returns the instanced database.
How it is “heavy” or fast/slow to create an instance of Database class? What if I do it every time when a DbCommand is needed?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这不是一个问题。 创建数据库类的开销很低。
然而，实际创建数据库连接的开销很高，这就是Windows使用连接池的原因。 简而言之，进程第一次创建数据库连接时，它会在连接池中查找具有完全相同连接字符串的现有连接。 如果找不到，则会创建一个新的（这是一项昂贵的操作）。 当进程关闭它并让它超出范围时，它实际上并没有关闭与数据库的连接，而是将其放入连接池中。 一直持续到同一进程使用相同的连接字符串创建另一个连接。 然后它会为您提供连接池中已有的连接。
您可以关闭连接池（通过连接字符串中的设置），但这通常是一个非常糟糕的主意。
It's not a problem. Creating the database class has low overhead.
However, actually creating the database connection has high overhead, which is why Windows does Connection Pooling. Briefly, the first time a process creates a DB Connection, it looks in the connection pool for an existing connection with exactly the same connection string. If it doesn't find one, it creates a new one (an expensive operation). When th process closes it and lets it go out of scope, it doesn't actually close the connection to the DB, it puts it in the Connection Pool. There is stays until the same process creates another connection with the same connection string. Then it gives you the already existing one from the Connection Pool.
You can turn off connection pooling (via a setting in the connection string) but that's usually a very bad idea.