用实体框架替换ADO.NET。实体框架是否适合以下场景？

Question

问题1：我们是否应该在多用户环境中使用Entity Framework来实现在表上执行多个更新（100行）的功能？

问题2：我们是否正确决定在以下情况中使用EF？

场景：Stock Count网页包含一个可编辑的gridview控件，允许用户一次更新100行。

背景：库存计数用于记录期间结算时的库存数量。所有组织的关闭期限发生在星期一。大约有10个实时组织，平均每个组织至少有100多个网站，同时在周一同时关闭。

基于ADO.NET的类似屏幕工作正常。然而，该团队正试图在新屏幕上引入实体框架。我们进行了方法水平压力测试，并没有获得有希望的EF结果。我们运行了2分钟的测试并模拟了从5个用户到35个用户的用户负载。

以下是结果：

ADO.NET 使用存储过程一次更新一个数据库。

5 Users - Number of test per second per user - 80
35 Users - Number of test per second per user - 150

EF 使用SaveChanges（）方法，该方法在内部一次更新一个数据库。

5 Users - Number of test per second per user - 43
35 Users  - Number of test per second per user - 43

EF代码：

方法1

context.Configuration.AutoDetectChangesEnabled = false;
context.Set<LocationData>().AddRange(data); //data is a collection of LocationData
foreach (var locationData in data)
{
    var entry = context.Entry(locationData);
    entry.State = EntityState.Modified;
}
context.SaveChanges();

方法1的代码分析器详细信息

方法2

context.Configuration.AutoDetectChangesEnabled = false;
foreach (var locationData in data)
{
    context.Set<LocationData>().Attach(data); 
    var entry = context.Entry(locationData);
    entry.State = EntityState.Modified;
}
context.SaveChanges();

方法2的代码分析器详细信息

实体框架生成的SQL查询

exec sp_executesql N'
UPDATE [dbo].[LocationData]
SET [LocationId] = @0, [ClientId] = @1, [ProductId] = @2, 
[SupplierProductId] = @3, [MenuId] = @4, [MenuNumber] = @5, [CaskNumber] = @6
WHERE ([Id] = @7)',N'@0 bigint,@1 bigint,@2 bigint,@3 bigint,@4 bigint, @5 bigint,@6 nvarchar(64),@7 bigint',
@0=22371851,@1=22371851,@2=22371851,@3=22371851,@4=22371851,@5=22371851,@6=N'Cask0091',@7=22371851

ADO.NET生成的SQL查询

Update LocationData
set 
 LocationId = @LocationId, 
 ClientId= @ClientID,  
 ProductId= @ProductId, 
 SupplierProductId=@SupplierProductId,  MenuId= @MenuId, 
 MenuNumber= @MenuNumber, 
 CaskNumber= @CaskNumber
WHERE   LocationData.Id = @Id

这些测试未在交易下执行。

我使用了以下用于开发：Visual Studio 2012 Ultimate，Sql Server R2，Entity Framework 6.0.2，.NET 4.5，C＃

Answer 1

不。实体框架简化了大型模型体系结构，并自动生成SQL以执行硬“复杂”位。如果您使用EF来实现简单的读/写实用程序类型，那么最好使用ADO.NET。如果您希望标准化并简化一组开发人员使用SQL Server的方式，则应使用实体框架。