我写了很多的帖子关于orm,今天我还想再说一遍:在关键的高并发的Web应用程序中使用ORM工具,是在过去几年中软件阶级所做的最伟大的愚蠢架构。
我写了很多的帖子关于orm,今天我还想再说一遍:在关键的高并发的Web应用程序中使用ORM工具,是在过去几年中软件阶级所做的最伟大的愚蠢架构。
WEB应用程序的瓶颈都在服务器的资源;内存和处理器的时间. 这些都是有特别高的成本。
让我们从0开始回顾一下一个http request是如何被处理的:
1.加载和初始化数据库的context,
2.把LINQ表达式编译转换成SQL语句,
3.发射SQL到服务器上 ,server 编译sql, 生成执行计划 ,优化查询,
4. 执行编译后的query,
5.转换结果为无类型的ADO数据集,
6. 生成有类型的ADO数据集,
7.使用反射 这种 最没有效率的方式 生成 实体 实例
8.从实体创建可序列化的对象,
9.创建XML或JSON对象,并将其传递到 output stream。
只有2个步骤是为任务(4和9)中的所有其他必要的 - 垃圾。考虑到EF(V3.5至少)会产生非常低效的查询与很多 子查询,这使得SQL服务器不得不一直工作在效率最低的模式。
建议:
使用LINQ to DataSet中(http://msdn.microsoft.com/en-us/library/bb386977.aspx)作为一种重量轻的工具Web应用程序。
使用LINQ to DataSet 你会得到少得多几乎相同的结果。而且还非常快.几乎是工业应用中最快的解决方案了.
当然, 对于小型数据库小型/个人网站我 使用LINQ to SQL /entity framework/ hibernate ... 或任何其他的ORM我想不是问题。
但是,对于专业网站,性能确实很重要,天下武功,唯快不破.
我学会了永远不要依靠一个ORM。纯粹的ADO,是唯一的答案,没有什么比它的性能更好了。当然这可能需要更长的时间来写DAL,但一旦这样做了,我相信我不会有任何其他的问题。
要知道,所有的ORM都有自己的问题,缺陷,性能问题和解决这些轻松的时间比任何时候我会用写纯SQL更多的时间。
当然,这是假定开发者能够编写DAL,并且有足够的智商来理解sql。 现实很简单,要么和orm一起完蛋,要么拿起了一本书,好好学习SQL。
学习SQL,绝对是个好主意,因为它似乎很多开发员甚至没有基本的SQL知识。你懂,你就赢了.