c# LINQ to SQL更新数据库之性能测试

在上一篇随笔中，我们列举了使用LINQ to SQL对数据库进行更新的5中方案。本文将对这几种方案进行测试和对比，力求找出一个最佳实践。

准备工作

我们的测试还是基于Products表。为了使测试更符合实际，我们将与之关联的Categories、Suplliers和Order_Details表都添加进来。首先创建一个IProductRepository接口，定义插入、查找、更新操作：

public interface IProductRepository { product); id); product); }

然后创建一个AbstractProductRepository抽象类，实现IProductRepository接口。由于插入操作都是一样的，我们在抽象基类中提供了默认实现。同时还提供可选的查询操作，因为除了“禁用查询跟踪”方案外，其余的查询操作也是一样的。

IProductRepository { product) { (); db.Products.InsertOnSubmit(product); db.SubmitChanges(); } id) { (); return db.Products.SingleOrDefault(p => p.ProductID == id); } product); }

接下来创建各个方案的实现类（具体的代码请参考文章最后的下载链接）：

方案一 重新赋值：CopyPropertiesProductRepository

方案二 禁用对象跟踪：EnableObjectTrackingProductRepository

方案三 移除关联：DetachAssociationProductRepository

方案四 使用委托：UsingDelegateProductRepository

开始测试

计时器采用CodeTimer，由于在下开发用的机器是XP（汗一个），所以使用的是修改版的CodeTimer。

我们对每个方案分别执行一次插入、查找和更新操作，代码如下（方案四的代码略有不同）：

pr) { Product { CategoryID = 1, ProductName = "Before changing", SupplierID = 1, UnitPrice = (decimal)2.0, UnitsInStock = 100, Discontinued = true, ReorderLevel = 10 }; pr.InsertProduct(p1); var p2 = pr.GetProduct(p1.ProductID); p2.CategoryID = 2; p2.ProductName = "Arfer changing"; p2.SupplierID = 2; p2.UnitPrice = (decimal)3; p2.UnitsInStock = 200; p2.Discontinued = false; p2.ReorderLevel = 20; pr.UpdateProduct(p2); }

然后分别计时：

[] args) { ())); ())); ())); ())); Console.ReadLine(); }

执行100次的结果如下图所示：

执行1000次的结果如下图所示：

可见，使用反射复制属性的方法时最不可取的。实际上，即使不使用反射而直接复制属性，其性能都是最差的。下图是使用直接复制属性时的数据：

直观上来看，禁用对象跟踪方法似乎性能最好，委托次之。但这种差距我认为是可以接受的（1000次操作的执行时间之差在1秒之内，使用的对象数量也相差无几）。那么剩下的比较就在代码的简洁性和API的易用性等方面了。

禁用对象跟踪方法的代码略多，因为为了能够访问与查询对象关联的其他对象，必须使用DataLoadOptions类来进行加载。

id) { (); db.ObjectTrackingEnabled = false; (); loads.LoadWith<Product>(p => p.Order_Details); loads.LoadWith<Product>(p => p.Category); loads.LoadWith<Product>(p => p.Supplier); return db.Products.SingleOrDefault(p => p.ProductID == id); }

而方案四的API略显复杂，毕竟不是所有业务层的程序员都能对表达式树和委托运用自如。另一方面，这种接口的约束也过于宽泛，不太好控制。因此可以将方法签名改成如下的形式：

这样一来性能超越了方案二，执行1000次的截图如下：

方案四的优势似乎已经很明显了（当然单从执行时间上来说，方案二与其1秒以内的差距同样是可以忽略的），更少的代码，更快的速度。

然而让人遗憾的是，这仍然是一个避开Attach方法的方案。此外，由于必须将所有属性的赋值放置在一个委托中，也丧失了一定的灵活性。比如在实际的项目中，我们常常会希望获取到Product的实体后，针对每个属性做一些操作，在方法的不同位置对不同属性的值进行修改，然后再统一调用Update方法进行更新。这时方案四就显得很别扭了。

因此我更倾向于提供多个UpdateProduct方法的重载版本，在不同的场景下使用不同的重载。您的意见呢？

其他阅读

使用LINQ to SQL更新数据库（上）：问题重重

使用LINQ to SQL更新数据库（中）：几种解决方案

c# LINQ to SQL更新数据库之性能测试