公司项目要更换一个好的ORM框架,作为本人其实极其不愿意,但是没有办法,目前在测试和学习EF,遇到个以下问题。如果有好的通用解决方案,那我们就考虑用EF了,如果大神们有更好的、能保证经常更新的ORM,不妨也推荐一下给小弟,感激不尽。
问题如下:
1 @foreach (var item in entity.Categories) 2 { 3 <h3>@item.CategoryName<span> (@item.Products.Count) </span></h3> 4 foreach (var sub in item.Products) 5 { 6 @sub.ProductName @:、 7 } 8 }
示例用的Northwind库,迭代Categories表的中项目,同时算出该分类下Product的个数(@item.Products.Count)
这个显示和最终效果是没有问题的,但是我用SQL跟踪以后,发现仅算一个Count,他就要查一遍数据库,有多少个分类,它查多少次.
大神们是怎么解决这个问题的,用EF扩展吗?该怎么写?
你这样写(For each....)当然有多少个分类就要查几次啦。要不然你还想咋的?
你想要不这样,就不能这样写,比如你想一次性得到所有分类包含的产品数量,
可以这样
Select CategoryID, count(ProductID) from Products
group by CategoryID
你自己转化为LINQ写法,LINQ也是有GROUP BY 的。
这么写我也知道,可是你看,如果我这么写了,我还不如回归到借助代码生成器生成的普通三层或者工厂三层,我既省了网站刚运行起来的损耗,也不需要大量耗性能的反射,这样用EF就没有意义了呀?如果仅仅为了EF的一些特性,那我们这种中小型项目压根没必要啊?节省不了多少时间呀?
@Kevin.Choi: 中小型项目,我不清楚你的定义是什么样叫中小型的。这个可能各人不同看法。
至于ORM的好处,这个我也不好在这儿多争辩。
个人看法,反而是中小型项目适合ORM,大型项目要考虑更多性能问题。
小型项目更多考虑是快速开发,快速纠错。
大型项目反而不会天天修改数据库,而小型项目这样修改太正常了。
@Kevin.Choi: 另外一个新的(对你来说)技术,肯定使用上有诸多不便,
最好的方法是慢慢迁移,不过对公司来说慢的成本又太大。
习惯了以后,你会发现ORM在开发中的优势的。
@爱编程的大叔: 多谢指教.感激不尽.
别用 EF,可恶心了。现在都是使用的 Moon.Orm,可好用了。
赏5毛
比起EF,优势在哪…?
@Firen: 优势就是它叫 Moon.Orm,它就是比 EF 有优势,谁用谁知道。
呜呜.....雷到我了
@Moon.Orm塑造Orm经典: 你不给钱,这就成高级黑了...
@爱编程的大叔: 呵呵
cyq.data
EF不是这样用的吧!!!
你应该在底层把你要的数据结果处理好,在页面上遍历这个处理好的数据结果。。。
不管你底层用的是EF还是ADO.NET,你页面上的代码都应该是遍历这个处理好的结果,这样,即便是你底层不想用EF了,换成ADO.NET或者其它ORM框架,你UI层的代码是不需要动的!
还是谢谢.
EF比传统ado还是省去很多代码量的,况且你也得向楼上说的一样,先处理好返回一个json数据或者其他类型数据,然后才在页面上输出。