有关EF的代理类问题。
0
悬赏园豆：50
[已解决问题]
解决于 2015-11-17 21:48
使用EF查询出来的实体默认都是有一个代理类的，这个代理类到底起到了什么样的作用？
看有地方说代理类中有一个状态和真正的数据实体，对查询出来的实体的操作(修改，删除等)都是改变代理类中的状态，然后由DbContext操作代理类来完成映射过程。
但是如果设置了db.Configuration.ProxyCreationEnabled = false; 看提示应该是不创建代理类了 ，实际 测试的时候直接tostring()输出也不再会是输出代理类的一堆码号了，但紧接着直接调用Remove()方法却同样可以删除数据库中的数据，既然 DbContext不是直接操作实体而是操作代理类，那为什么不创建代理却还能直接Remove()成功呢（是直接Remove，没有先Attach）？ 又测试了一下发现
MessageBox.Show(dal.db.Entry(model).State.ToString());//Unchanged 我都没有代理类了，状态什么的也更谈不上了啊，怎么这里还是Unchanged 不是应该是Detached吗？
这样的话不就矛盾了嘛？还有说代理类是用于方便延迟加载的，EF的代理类到底起到了什么作用？有没有专门讲解EF实现原理的书籍？看网上都只有英文的。
最佳答案
0
这个应该分开来看
EF 维护的是一个实体的上下文状态，并不是代理类
能拿到Unchaged状态，说明这个实体在EF追踪上下文中，所以可以对它进行操作。
代理类的关闭，其实是停用了EF 的懒加载，一般会来提高查询效率上。
在你的实体存在 virtual 类型的属性时，代理类会对该属性产生影响（延迟加载）
蟋蟀有一片文章在说代理类，可以看看他的发现。
http://www.cnblogs.com/xishuai/p/ef-dbcontext-configuration-proxycreationenabled.html
收获园豆：50
汗。。看来代理类主要就是处理导航属性延迟加载的问题了，EF上下文对具体实体的状态追踪不是依赖代理类的 EF上下文对实体状态的维护也不是操作代理类来的了 感觉实际使用的高度和底层原理的高度差距太大了，很多博客的文章写得也确实是有点问题了，有点越来越迷糊的感觉了。
@迟鱼: EF是一个ORM 框架，它并不像webForm一样是那种托托控件就能使用的东西。需要多看看各种文章才能知道怎么才能用好。也就是因为这样，所有会有好多人说性能有问题，不好用。其实多数的情况下，都是开发自己的不理解。
@Sky.Grain: 我个人觉得，从追本溯源的角度来看，webform想研究透彻也是挺难的 涉及到内部的管道事件和页面生命周期里面一系列复杂的事件 比如事件回发处理机制等等 事实也证明webform也是能做大型网站的(比如起点,不过起点的页面上一点ViewState都没有，看来是基本没有服务端控件) 但是要好好处理服务端控件的使用问题。。
