使用LINQ to SQL更新数据库（下）：性能测试

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

准备工作

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

public interface IProductRepository
{
    void InsertProduct(Product product);

    Product GetProduct(int id);

    void UpdateProduct(Product product);
}

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

public abstract class AbstractProductRepository : IProductRepository
{
    public void InsertProduct(Product product)
    {
        NorthwindDataContext db = new NorthwindDataContext();
        db.Products.InsertOnSubmit(product);
        db.SubmitChanges();
    }

    public virtual Product GetProduct(int id)
    {
        NorthwindDataContext db = new NorthwindDataContext();
        return db.Products.SingleOrDefault(p => p.ProductID == id);
    }

    public abstract void UpdateProduct(Product product);
}

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

1. 方案一 重新赋值：CopyPropertiesProductRepository
2. 方案二 禁用对象跟踪：EnableObjectTrackingProductRepository
3. 方案三 移除关联：DetachAssociationProductRepository
4. 方案四 使用委托：UsingDelegateProductRepository 

开始测试

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

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

static void Execute(IProductRepository pr)
{
    var p1 = new 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);
}

然后分别计时：

static void Main(string[] args)
{
    CodeTimer.Time("Copy Properties", 100, () => Execute(new CopyPropertiesProductRepository()));

    CodeTimer.Time("Enable Object Tracking", 100, () => Execute(new EnableObjectTrackingProductRepository()));

    CodeTimer.Time("Detach Associations", 100, () => Execute(new DetachAssociationProductRepository()));

    CodeTimer.Time("Using Delegate", 100, () => ExecuteDelegate(new UsingDelegateProductRepository()));

    Console.ReadLine();
}

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

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

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

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

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

public override Product GetProduct(int id)
{
    NorthwindDataContext db = new NorthwindDataContext();
    db.ObjectTrackingEnabled = false;
    DataLoadOptions loads = new DataLoadOptions();
    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略显复杂，毕竟不是所有业务层的程序员都能对表达式树和委托运用自如。另一方面，这种接口的约束也过于宽泛，不太好控制。因此可以将方法签名改成如下的形式：

public void UpdateProduct(int id, Action<Product> action)

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

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

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

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

其他阅读

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

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

代码下载