实体框架 4：创建 EntityConnection 的成本有多高？
创建 EF4 EntityConnection 的成本有多高？我正在使用 SQL Compact 创建 EF4 桌面应用程序，用户将能够使用“文件打开”对话框打开数据库文件。然后，我的代码构建一个 EntityConnection，如下所示：
// Configure a SQL CE connection string
var sqlCompactConnectionString = string.Format("Data Source={0}", filePath);
// Create an Entity Connection String Builder
var builder = new EntityConnectionStringBuilder();
// Configure Builder
builder.Metadata = string.Format("res://*/{0}.csdl|res://*/{0}.ssdl|res://*/{0}.msl", m_EdmName);
builder.Provider = "System.Data.SqlServerCe.4.0";
builder.ProviderConnectionString = sqlCompactConnectionString;
var edmConnectionString = builder.ToString();
// Create an EDM connection
var edmConnection = new EntityConnection(edmConnectionString);
我有一个 ObjectContextFactory 类，它根据需要为 Repository 类创建对象上下文。
所以，这是我的问题：在初始化工厂时构建一次 EntityConnection 是更好的做法，还是工厂应该在每次创建对象上下文时构建一个新连接？感谢您的帮助。
How expensive is it to create an EF4 EntityConnection? I am creating an EF4 desktop app with SQL Compact, and the user will be able to open database files using a File Open dialog. My code then builds an EntityConnection, like this:
// Configure a SQL CE connection string
var sqlCompactConnectionString = string.Format("Data Source={0}", filePath);
// Create an Entity Connection String Builder
var builder = new EntityConnectionStringBuilder();
// Configure Builder
builder.Metadata = string.Format("res://*/{0}.csdl|res://*/{0}.ssdl|res://*/{0}.msl", m_EdmName);
builder.Provider = "System.Data.SqlServerCe.4.0";
builder.ProviderConnectionString = sqlCompactConnectionString;
var edmConnectionString = builder.ToString();
// Create an EDM connection
var edmConnection = new EntityConnection(edmConnectionString);
I have an ObjectContextFactory class that creates object contexts for Repository classes as needed.
So, here's my question: Is it better practice to build the EntityConnection once, when I initialize the factory, or should the factory build a new connection each time it creates an object context? Thanks for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知，EF4 的开销是最小的 - 请在此处进行验证 -基本上，这归结为打开一个新的数据库连接，如果提供程序支持连接池（SQL Server 支持），那么即使成本也很小。
MetadataWorkspace 中的元数据是全局缓存的，因此这不会降低性能（在 2009 年发布另一篇文章中链接的博文时，情况可能并非如此）。
此外，配置文件中的连接字符串（该博客文章中指出的其他性能问题）都缓存在内存中，因此我也看不出这会对性能产生负面影响。
我肯定会为每个工作单元使用新的实体连接。
The overhead in EF4 is from all I know minimal - please verify here - basically it comes down to opening a new database connection and even that cost is small if the provider supports connection pooling (which SQL server does).
Metadata from MetadataWorkspace is is cached globally so this will not decrease performance (that probably wasn't true in 2009 when the blog post linked to in the other post was posted).
Also connection strings from the config file (the other performance problem indicated in that blog post) are all cached in memory, so I can't see how this can negatively impact performance either.
I would definitely use a new entity connection for each unit of work.
查看这篇博文。似乎为每个上下文创建一个新的 EntityConnection 是一项昂贵的操作，并且是一些主要性能问题的根源。这些性能问题（在您的情况下）的根源是连接元数据的创建。本文中提到的其他性能影响（获取连接字符串 frmo config）不适用于您，因为您正在提供自己的连接字符串。在我看来，您应该创建一个 EntityConnection。
要记住的一件事是，根据文档< /a>，EntityConnection不保证线程安全。如果您要从不同的线程访问这些连接，那么您将遇到问题，解决此问题的最安全方法是不重用 EntityConnection。
Take a look at this blog post. It seems that creating a new EntityConnection for each context is an expensive operation and the source of some major performance problems. The root of these performance issues (in your case) is the creation of the connection metadata. The other performance hit mentioned in the article (getting the connection string frmo config) would not apply to you, as you are supplying your own connection string. In my opinion, you should create a single EntityConnection.
One thing to keep in mind is that according to the documentation, EntityConnection is not guaranteed to be thread safe. If you are going to be accessing these connections from different threads then you will run into problems, and the safest way to solve this would be to not reuse the EntityConnection.