MVC UnitOfWork EntityFramework架构

MVC UnitOfWork EntityFramework架构，网站速度慢的原因总结！

最近参考使用了郭明峰的一套架构来做新的项目架构，这套架构看起来还是不错的，先向小郭同学的分享精神致敬！

（郭同学的项目文档：http://www.cnblogs.com/guomingfeng/archive/2013/05/19/mvc-overall-design.html）

项目开发上线后，傻眼了，貌似没有几个人访问的新项目，速度一直慢的跟牛一样，真心没法交差啊。上面发下话了，解决不了就可以走人了。压力可想而知。

接下来就是苦逼的找原因了。

症状：1、内存占用高，8g的内存很快就能吃完

2、网站相应速度慢，firebug检测每次都是在等待

根据这些症状，感觉是内存泄露了，于是memory profiler。。。什么性能分析工具都用上了，怎奈水平有限，不会使用这些高级玩意，一番折腾下来，就剩下无奈。

但总不能放弃，对比之前做的mvc项目，就是多了entityframework、MEF这两样，看样子也就这两块的原因了，EF的嫌疑最大，而且首次使用，并不了解。于是，接下来又是一段苦逼的研究；功夫不负有心人，根据目前研究的结果及上线的效果来看，基本上找到了问题的所在。总结下，与诸位分享，高手忽略。

问题原因：1、很多数据查询一次性读入到内存中，导致内存增加。

2、上下文对读入到内存中的数据对象会进行跟踪，导致内存不断攀升，疑似内存泄露

解决办法：1、深入学习EF，监控每一步生成的sql语句，防止无用数据的调取

2、网站大部分的数据在读取的时候是不需要进行上下文跟踪的，一定要禁止跟踪，否则内存就会爆了！代码如下：

/// <summary>
        /// 获取当前实体的查询数据集(通过读上下文进行读取，只读专用，返回的实体数据不会被上下文跟踪)
        /// </summary>
        public virtual IQueryable<TEntity> ReadEntities
        {
            get { return WriteContext.Set<TEntity>().AsNoTracking(); }
        }

        /// <summary>
        /// 获取当前实体的查询数据集(通过写上下文进行读取，修改专用，返回的实体数据会被上下文进行跟踪)
        /// </summary>
        public virtual IQueryable<TEntity> WriteEntities
        {
            get { return WriteContext.Set<TEntity>(); }
        }

说明：我在仓储模式中，对读取实体集合进行了修改，ReadEntities表示不需要进行跟踪的，加上AsNoTracking方法；WriteEntities表示是需要跟踪的，用于修改实体信息使用。这样以来，所有的症状全部消失了。

当然，也许有更好的优化方法，至少目前本人发现了这些问题所在，而且微软的白皮书中确实也讲的了EF的性能注意事项，怎奈仓促开发，对EF毫不了解，罪过罪过！大家引以为鉴！

另外，还遇到一个问题，不知道是否是DBcontext线程冲突问题，大家帮分析下，谢谢：

 

 

 

标签: MVC, UnitOfWork, EntityFramework, 速度慢