Entity Framework 4 In Action是本人这么多年来读的第一本英文书了，一开始为了读这本书去学英语，后来干脆边读边学，看了几章，英语阅读能力大大的提高了。可惜看到最后，说实话没学到什么实质性的东西，只当是学英语了。当然，说没学到什么实质性的东西，是因为大部分知识都零零散散的在论坛上，博客上都看过了，书本身是很有内容的，这是国外的作者写的书的特点，没有废话，没有为了凑页面而来的大堆的代码。作为EF的初学者还是很适合去读读的。接下来谈谈看完后的一些感想，作一下记录。
谈谈lifecycle
本书在第六章详细介绍了实体对象（Entity）的生命周期（lifecycle），这里的生命周期，指的是EF中的实体对象的5个状态。
当你在执行插入、修改、删除 操作时，就是它们发挥光和热的时候，查询数据的时候是没有作用的。EF提供了丰富的接口允许你随意的切换一个实体对象甚至是对象中某一个属性的状态，目的就是减少你跟数据库打交道的次数。比如下面一段代码：
1 IBacterName name = bacterNameRep.GetById(applyinfo.BacterNameId); 2 ISupplier supplier = null; 3 if (applyinfo.SupplierId.HasValue) 4 { 5 supplier = supplierRep.GetById(applyinfo.SupplierId.Value); 6 } 7 IBacterBuyApply bacterBuyApply = _factory.CreateBacterBuyApply(name, applyinfo.Amount, rangeId, rangetype, userId, supplier,(e_UnitType)name .InjectUint); 8 _bbar.Add(bacterBuyApply);
为了插入一个IBacterBuyApply对象，我在第一行和第五行代码从数据库取出了两个对象。也就是说，为了执行一个插入操作，我比用原生态的ADO.NET多查询了两次数据库。
当我刚使用EF时，这让我很不能接受，怎么办呢,使用Attach方法。它能使我们避免这两次无意义的查询，代码就不贴了，大家都懂的。。。
可是，这样做真的合适吗？ 我觉得不，因为我们的代码总是一层层的划分好，我不知道诸如上面一段代码大家都会放在什么层里面，可它肯定不叫“EF层”。我要说的是，当我们使用类似如Attach这样的方法时，它破坏了我们的代码结构，让我们的代码变的不纯洁。因为原本一段跟你的数据库访问架构无关联的代码，被拴在EF这个组件中。当然上面这段代码是我在08的项目中截下来的，在EF4.0中，因为允许存在外键，已经不存在这个问题，但这不影响我要表达的意思。不知道大家怎么看待这个问题。
谈谈书中提到的几点性能优化
当我即将读完本书的第三部分时，我就直接跳到了最后一章的性能优化部分。我一点一点的谈谈书中提到的几点优化建议。
- 首先书中提到Entity SQL快于Linq to Entities。那么我们要使用Entity SQL？ 既然都Entity SQL了，何不Ado.net，反正都是运行时错误。用EF最大的好处就是编译时错误。没了这个，我觉得没有使用的必要了。
- 缓存编译后的Linq to Entity--缓存的是表达式树（Command Tree）不是SQL。从Linq to Entity 翻译为 SQL，需要相当的时间，缓存之后，下次再执行，就少了翻译表达式数这一步骤，提高速度。但这种方法也是有缺陷的，当你取出编译后的表达式树，去连接其他Linq to Entity 语句时，缓存效果就失效了，这意味着，在我们的查询页面中，如果用户不停的变化查询参数的组合，缓存是无效的，仅仅是查询之后，翻翻页，还有效果。
- 关闭状态追踪。EF会维护从数据库中取出的对象的状态，这需要相当大的资源消耗，关闭它会获得相当大的性能提升。然而这似乎没什么意义，因为只有在数据浏览页面，我们才需要取出大量的数据，而正是在数据浏览页面，我们通常需要取出多个表的数据--连接查询，为了取到其他表的字段，大家是怎么用的呢？LoadWith？我经常需要在一个查询中关联四个以上的表，我看LoadWith才是性能杀手。显然，隐射（Projection）各个表的字段到一个新的数据传输对象中才是合适的做法。而当你这么做的时候，状态追踪已经失效了。。。。
嘿嘿，关于优化我曾经作用小小的探索，贴个链接 http://www.cnblogs.com/xxfss2/archive/2012/06/15/2550826.html
最后说说Entity Sql
Entity sql 最大的作用就是当你无法用Linq to Entity 写出查询语句时，它能写出来，可是，真有这样的时候，我觉得使用存储过程更适合。另外它能以扩展方法的方式动态的拼接语句，比如当你的排序字段非常多时，可是这也没有必要，随便网上找个通过动态构造表达式树的扩展方法就可以解决这个问题。总之我觉得EntitySql是个鸡肋，书中也提到，一开始发明它纯粹是因为Linq还没出来，可怜的替代品而已。