至今,面试了很多人,和我说EF/LINQ/ORM效率低的,几乎90%说不出所以然,最多是说网上说的,10%能给我扯一些转换为sql语句有损耗,极少能说出生成sql语句冗余效率低/数据转换为实体有性能消耗(并不错,但不全面) 首先,需求第一,技术是为需求服务的。撇开需求,说性能没实际意义。Linq2EF的性能要从好多方面看。 表达式树-SQL的转换/数据-实体的转换/数据的缓存/批量数据更新的不便/语句执行效率可能不是最优/程序员对EF(表达式树)的理解太浅导致滥用 等等。不能一概而论。 EF可能带来的好处很多人也都有论述,包括语法编译时检查/跨数据库支持/快速开发 等等。 最终是否决定使用这个技术,是综合起来考量,是否为了微不足道的性能提升而放弃开发便利性?是否为了能简单的支持多种数据库而牺牲一些数据更新上的便利性和性能等等。 很多时候,一个项目并非完全是EF写增删改查的,EF更主要是功能是查询,有些时候批量数据更新会封装到存储过程中处理,有时候会结合一些缓存来使用EF等等。 最后说一句,目前见过的绝大多数EF性能问题往往出自程序员对linq2ef表达式树的滥用。
EF是富ORM,它在转化成ADO.NET之前有一定的性能消耗,当然这是所有ORM工具都存在的问题 另外它自动生成的SQL并不一定是最优的SQL,这对于不了解SQL优化的人来说是不错的,但对于需要进行优化的就比较蛋疼,当然EF也支持直接用SQL查询 另外EF还实现了CodeFirst,数据缓存之类的东西,简化了开发 反正最终就一句话,每种工具都有它的优势与劣势,只有用在最适合的地方才能发挥出最大的效用 如果你想要效率,那么就是ADO.NET效率最高,次级的就是那些轻型ORM,比如Dapper之类的,它就只是实现了查询结果与实体的映像
Linq 跟关系数据库有直接关系吗?每一种关系数据库的 Linq Provider 都不一样,注意不要“排便困难,反而埋怨厕所有问题”。 谁知道你怎么写查询的?
8,497
社区成员
4,736
社区内容
加载中
试试用AI创作助手写篇文章吧