前言

在工作当中呢，没怎么用到过EF，所以为了遗忘这一部分知识，偶尔会去写写小的demo，偶然机会在EF循环迭代中发现居然影响性能这么严重，当我们在用时或许大概也许可能都曾这样写过，但是你注意到了吗，你怀疑过吗？这就是本节所要讨论的话题。若有错误，请批评指出。

话题

关于基础知识我们就不废话了哈，我们假设这样一个场景（不一定严谨，只是为了引出话题）：当在下单中，如果有多个人下单，此时我们需要通过订单Id去得到客户Id。在这一场景中我们给出一个订单类以及订单处理类。如下：

     //订单类

     public class Order

    {

        public int Id { get; set; }

        public int OrderId { get; set; }

        public int CustomerId { get; set; }

        public string Filed1 { get; set; }

        public string Filed2 { get; set; }

        public string Filed3 { get; set; }

        public string Filed4 { get; set; }

        public string Filed5 { get; set; }

    }

    //订单处理类

    public class OrderProcess

    {

        public int OrderId { get; set; }

        public int CustomerId { get; set; }

    }

订单类是poco类存于数据库中，而订单处理类为将订单类进行DTO的类，我们将订单Id传到订单处理类中，通过订单类来获取到客户Id并赋给订单处理类中的客户Id。

为了大家可能方便测试，将其余说了很多次的映射类以及上下文都给出来。

    //订单映射类

    public class OrderMap : EntityTypeConfiguration<Order>

    {

        public OrderMap()

        {

            HasKey(k => k.Id);

            Property(p => p.OrderId);

            Property(p => p.CustomerId);

            Property(p => p.Filed1);

            Property(p => p.Filed2);

            Property(p => p.Filed3);

            Property(p => p.Filed4);

            Property(p => p.Filed5);

        }

    }

    //EF上下文以及预热

    public class EFDbContext : DbContext

    {

        public EFDbContext()

            : base("name=EFIteration")

        {

            var objectContext = ((IObjectContextAdapter)this).ObjectContext;

            var mappingCollection = (StorageMappingItemCollection)objectContext.MetadataWorkspace.GetItemCollection(DataSpace.CSSpace);

            mappingCollection.GenerateViews(new List<EdmSchemaError>());

        }

        /// <summary>

        /// 通过反射一次性将表进行映射

        /// </summary>

        /// <param name="modelBuilder"></param>

        protected override void OnModelCreating(DbModelBuilder modelBuilder)

        {

            var typesRegister = Assembly.GetExecutingAssembly().GetTypes()

                .Where(type => !(string.IsNullOrEmpty(type.Namespace))).Where(type => type.BaseType != null && type.BaseType.IsGenericType && type.BaseType.GetGenericTypeDefinition() == typeof(EntityTypeConfiguration<>));

            foreach (var type in typesRegister)

            {

                dynamic configurationInstance = Activator.CreateInstance(type);

                modelBuilder.Configurations.Add(configurationInstance);

            }

        }

    }

在数据库中对订单表生成了20万条数据。我们在订单处理类中随机插入100条订单Id，如下：

            var orderProcessList = new List<OrderProcess>();

            for (int i = ; i < ; i++)

            {

                var random = new Random();

                var number = random.Next(, );

                var orderProcess = new OrderProcess() { OrderId = number };

                orderProcessList.Add(orderProcess);

            }

为了将订单类中客户Id赋给订单处理类中客户Id，你是不是会像如下这样操作呢？

            var context = new EFDbContext();

            foreach (var op in orderProcessList)

            {

                var order = context.Set<Order>().FirstOrDefault(o => o.OrderId == op.OrderId);

                op.CustomerId = order.CustomerId;

            }

此时我们来测试下耗费的时间。

结果是3.2秒，看到这里有人就说了，而且大家都看到过都知道，在查询时为了性能我们可以关闭EF的变更追踪，于是乎就有了下面的代码：

改良一

 var order = context.Set<Order>().FirstOrDefault(o => o.OrderId == op.OrderId);

//替换成

 var order = context.Set<Order>().AsNoTracking().FirstOrDefault(o => o.OrderId == op.OrderId);

此时看看演示结果：

此时耗费的时间为1.7秒，当然有时会更短，反正比上述加了变更追踪情况的耗费时间要少。

到了这里你是不是就觉得已经很满足了呢？是不是觉得已经得到了很大的改善了呢？要是这样关闭变更追踪就可以解决了问题，那我这篇文章你说还有什么意义呢？好了废话不多说。本文讨论的话题就在于EF循环迭代问题，难道仅仅只有上述一种方式能达到我们的需求吗，上述我们将EF迭代放在了遍历订单处理类中，我们难道就不能事先得到符合条件的订单Id，然后直接取到对应的客户Id呢？思路来了，说完就开始干。

改良二

（1）筛选出符合订单处理类中的订单。

            var orderToProcessIds = orderProcessList.Select(o => o.OrderId).ToList();

            var allOrders = context.Set<Order>().AsNoTracking().Where(o => orderToProcessIds.Contains(o.OrderId));

（2）将符合条件的订单转换成以订单Id为键的字典。

            var allOrdersDictionary = allOrders.ToDictionary(o => o.OrderId);

            foreach (var op in orderProcessList)

            {

                var order = allOrdersDictionary[op.OrderId];

                op.CustomerId = order.CustomerId;

            }

这样不就解决了每次都要去迭代订单吗。接下来我们来测试比较改良一和改良二中耗费的时间。

改良一中的耗时为3.4秒，改良二中耗时为0.3秒，通过小小的改善是不是又将性能提升了10倍呢！不必多说，你懂的！

总结

本节我们验证了在EF循环迭代中会导致性能的丢失，我们不经意间的操作就导致性能的丢失，有时候转换思维很重要，不仅仅只局限于固定思维，从上面可以看出：能够避免的应该尽量避免在遍历数据时去进行EF的循环迭代。好了，本来打算早点睡觉的，偶然发现这样也会导致性能的丢失，于是马不停蹄导致本文的产生。

【Advertisement】：最近找工作中，工作地点：深圳，希望大家可以推荐推荐！

巴特西

EF循环迭代导致如此严重的性能丢失，你知道？

前言

话题

改良一

改良二

总结

最新文章

热门文章