CVM.北湖
这个怎么产生这么多嵌套对性能有什么影响，大家给看看。CVM.北湖
是的。看看代码合理不？CVM.北湖
性能
嗯，mvc里面的一步一般什么时候用比较合适？
湾台自来我
如果你要考量SQL生成語法效能 那就是用錯地方了
krap↑niknil
http://www.cnblogs.com/zhaopei/p/5721789.html#autoid-0-0
你可以看看农码这篇EF文章 找找点
krap↑niknil
找找感觉
EF的sql就那样的
湾台自来我
其實 這篇文章沒有任何意義
不是說文章內容不對
而是正確用EF根本沒這些問題
udutum
ef+dapper吧
ef就只用在它该用的地方
湾台自来我
恩
EF只應該用在業務
前提是面向對象
非面向對象設計用EF 最後都是坑
用越久了越明白這一點
legnA的中云
、这种会生成101条SQL？
白小sIemaNyM
如果用到很复杂的where 那么你就考了是不是要换个做法了
湾台自来我
他寫錯了吧
應該是101條數據
呀
看錯了
他標錯地方了
他是指下面的foreach循環
krap↑niknil
ToList 是查的Score
krap↑niknil
100个是查score关联的student
湾台自来我
如果你是使用聚合設計...
根本沒有延遲加載問題
krap↑niknil
什么是聚合设计
不关联吗 不同virtual
legnA的中云
这篇文章我觉得对于我们这种菜鸟还是非常有帮助的
湾台自来我
把具有原子性的對象放在一起
這些對象是共生共滅的
自然沒有延遲加載問題
因為讀取時都是一起加仔的
如果設計成對象樹
那麼就會衍生出延遲加載問題
因為如果沒有延遲加載 會產生很大性能問題
不知道要加載到第幾階
legnA的中云
这篇文章太好了，我正需要这样的文章！
CVM.北湖
看了一下好像都是英文的
中文了现在还没有人翻译。
我也正想找。
湾台自来我
沒有
這問題已經很久了
很奇特
NH都出了好幾本中文
EF卻沒人翻譯
明明EF用的人更多
CVM.北湖
是不是微软了技术没落了，或者是用的人少了。没有什么市场？
