是否有任何替代方案不会关闭与 ExecuteStoreCommand 的连接
我们正在谈论每个请求一个 ObjectContext 的概念。 （网络应用程序） 我们不关闭Application_BeginRequest和Application_EndRequest之间的连接。 请求期间我们有一个 ObjectContext。 我们在请求期间打开它并且不关闭。
实体框架中有一个 ExecuteStoreCommand 但这对性能来说有点危险。因为当我们使用它时（我认为）它会关闭连接。当我们在连接再次打开后使用 ObjectContext 时（这是性能问题？）
那么有没有 ExecuteStoreCommand 的替代方案，或者我疯了:)
We are talking for one ObjectContext per Request concept. (Web Application)
WE dont close connection between Application_BeginRequest and Application_EndRequest.
We have a single ObjectContext during the Request.
We open it and dont close during the Request.
There is a ExecuteStoreCommand in Entity Framework but this is a little dangerous for performance. Because when we use it (I think) it closes a connection. And when we use ObjectContext after it connection is opened again (this is performance problem?)
So is there any alternative to ExecuteStoreCommand or am I crazy :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果正确使用连接池。连接池保存多个打开的连接，这些连接可供多个后续操作重用。在大多数情况下，打开仅意味着“从池中获取连接”，而关闭意味着“将连接返回到池中”。如果池中没有可用连接，连接池将处理打开新连接，并限制并发使用的连接数量。连接池是根据连接字符串+用户身份定义的。
仅当命令开始执行时没有打开连接时，
ExceuteStoreCommand才会关闭连接。这意味着如果您使用传递给上下文的自己的连接，它将不会关闭它。"Closing" and "Opening" connection doesn't have any real performance impact if you correctly use connection pooling. The connection pool holds several opened connections which are reused by multiple subsequent actions. Open in most cases only means "get me a connection from the pool" and close means "return the connection to the pool". The connection pool will handle opening a new connection if none is available in the pool as well as limit number of concurrently used connections. Connection pool is defined per connection string + user identity.
ExceuteStoreCommandcloses connection only if no connection was opened when the command started execution. It means that if you use your own connection passed to the context it will not close it.