可怜的程序员!对EF说不!

xuejie09242 2009-06-12 11:24:13
今天在网上发现了VS2008SP1上自带的EntityFramework的介绍,因为自己在以前的开发中,曾经为OR影射类似的问题思考过,民想过一些办法,因为事情比较多,未做深入的思考。待我仔细看来,天!好庞大的框架啊,怪不得说在.NET2.0下就想加入的,到了现在才加到VS中呢,把一个数据库访问分成许多层,概念层,存储层,影射层等,还有客户端,服务层,动态数据,令人一下子摸不着头脑。都是干什么用的?又能达到什么效果,解决什么样的问题?在网上查了,发现没有一个从总体介绍是什么,各层之间的联系,怎么配合,完成什么样的功能之类的介绍,都是象教孩子一样,一步一步,那个详细,你就这样就行,具体为什么,不要问,你不需要知道的。

  大体看了些,还摸不着门道,竟然还有自己的语言,Esql,还美其名曰 从Sql编码中把程序员解放出来,这简直是天大的谎话!一个程序员要用好这个框架,除了学程序设计语言的语法,还要学所谓的Esql语法,还有linq,还有可能必须编写SQL脚本,哈哈,看来程序员的负担不是轻了,而是重了。现在的程序员就象傻子一样,一味地学着别人的接口,三天两头一变,却不知里面的思想,别人为什么这样,能解决什么问题,不能解决什么问题,只知道一味地去学,做了几年十几年的程序员,还是围着别人的圈在转,没有自己的思想,没有自己的技术,并以自己学会多少别人的东西自豪。这也许是许久我们没有自己完全意义上操作系统的原因吧,呵呵。

  做这样的程序员,做的工作就象搬砖,做的再多,也是力气活,一个月给你一两千的工资,乐的屁颠屁颠的了,混口饭吃吗,作为一名程序员,也就这样了。

  微软的东东,凭心而论,不能说没有可取之处,就是太复杂了,虽说里面有些设计思想还是可圈可点的,但从效果上来看,还是增加了程序设计者的负担,隐藏了技术细节,使开发者疲于学习各种不同的接口,从长远看来,促使开发工作分工,每个人好象生产线上的一环,干好自己那点就行了,至于别人怎么样,总体是什么,不用明白了。这种情形下的程序员,就象生产线上的工人,做的是一样性质的工作。做这样的程序员,也就是能吃饱的程序吧。

  从执行效率上讲,利用Ado .net直接用SQL访问数据库,或者多层结构中,利用应用程序服务器负责对DB的访问,客户端与DB间最多有一层,而应用了这个框架,中间就多了好几层,还有语言之间的转换,其执行效率肯定和直接和SQL访问DB差许多了,怪不得微软的软件基本上都可以充分利用硬件方面的最新成果了,每出一个版本,基本上都要在最新的硬件平台上运行,如果是比较早的机器,那就直接扔吧,呵呵!

  这样的框架,远没有一个直接能够产生常用SQL的自动代码框架,可以生成SQL代码,也可以生成N层结构框架代码,现在已经不少这样的工具,用这样的工具才是真正的提高效率。面对MS的EF,我要说88了您的!


没分可散,希望大家热情积极参与讨论,哈哈!
...全文
145 14 打赏 收藏 转发到动态 举报
写回复
用AI写文章
14 条回复
切换为时间正序
请发表友善的回复…
发表回复
jzywh 2009-06-14
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 xuejie09242 的回复:]
楼上,我的意思只是我不想用EF,和ORM无关,我也没说ORM会性能低下,至于第三点,我同意!自己编三层,当然一些相关的OO设计模式的知识还是要知道的,要不,还不如只学接口,用别人的,呵呵。

我的意思只是说EF我觉得不够小巧,所以不够 好,我不会用它。二,现在的开发商也是一层层的往上加,搞的越来越复杂,这方面他们也是有问题的,三,程序员很多都是忙着学接口,学会了几个方法和函数,就自以为是,我是很不以为然的。…
[/Quote]

软件开发过村中存在的主要问题是什么?

解决复杂问题。 如何解决复杂问题呢?

复杂问题简单化.

一些应用程序库可以很好的解决这些问题,我们可以不知道这些库的内部实现,而通过简单的调用来实现以前需要很多coding的功能。
如果你觉得使用这个库反而比直接coding更麻烦,那要么说明这个库不好,要么你没有正确使用这个库。
我觉得EF的情况应该属于后者。

批评一样东西, 我觉得应该先对它有6分了解,不敢说10分。

楼主谈到了技术的方法和目的,我觉得这个话题的方向很好。
我们做软件的目的是什么?到底是什么呢?
是自己的开发的水平提高吗? 我认为不是的。
开发出成功的软件项目/产品才是目的。
什么样的方法才是好的软件开发方法呢?
高效率,高质量的软件开发。
HimeTale 2009-06-13
  • 打赏
  • 举报
回复
估计是经验少导致楼主不理解。

有了模式设计基础再看看敏捷开发相关书籍也许就明白了。
xuejie09242 2009-06-13
  • 打赏
  • 举报
回复
楼上,我的意思只是我不想用EF,和ORM无关,我也没说ORM会性能低下,至于第三点,我同意!自己编三层,当然一些相关的OO设计模式的知识还是要知道的,要不,还不如只学接口,用别人的,呵呵。

我的意思只是说EF我觉得不够小巧,所以不够 好,我不会用它。二,现在的开发商也是一层层的往上加,搞的越来越复杂,这方面他们也是有问题的,三,程序员很多都是忙着学接口,学会了几个方法和函数,就自以为是,我是很不以为然的。
所以说,所有的技术,和方法是和目的分不开的,在你选择框架和接口的时候,别忘记自己的要求,然后去有选择的学习,还可以通过学习别人框架的代码和接口以提高自己。学会选择,别迷失了自己就好。
iloveppmm 2009-06-12
  • 打赏
  • 举报
回复
lz 为什么不好好研究下EF呢?



ORM框架,JAVA 那边据说用的很普遍啊,EF难道不是ORM框架吗?? 怎么到了微软这就成了负担了??

如果比其他的orm 框架差,那需要你的对比。

可lz 简直在说ORM是垃圾啊,虽然用EF替代了ORM。

yuangang1011 2009-06-12
  • 打赏
  • 举报
回复
顶!
zorou_fatal 2009-06-12
  • 打赏
  • 举报
回复
在没有理解之前就下结论是不理智的行为。
wjq 2009-06-12
  • 打赏
  • 举报
回复
有必要这么积极抵触么?
执行效率来说也许比不上高手写的SQL,但也不会比大多数人写的SQL差多少,真有遇到需要效率的,还可以写了sp隐射成一个方法。
作为一个ORM框架,提供的基础功能:DB->Class的隐射也比大多数相关工具好。

也许搞了EF,要学Linq/lambda/Esql,但Linq作为C#3里的一个不错的特性,也该学习一下,这可爱的语法糖可以让你省不少事,Esql来说,如果只是那EF和不少ORM框架来比,也不需要用~

MS的东西,只要它有升级的连续性,用用还是不错的吧。
windstore 2009-06-12
  • 打赏
  • 举报
回复
说的大实话,顶!
jzywh 2009-06-12
  • 打赏
  • 举报
回复
[Quote=引用 10 楼 xuejie09242 的回复:]
请问,我有一个轻量级框架,可以自动生成SQL代码,读取数据库结构自动生成多层代码,可以是简单三层,Web service等方式,这就难维护吗?你据说的可维护性又在哪呢?
[/Quote]
你的观点是EF不好还是ORM不好?

[Quote=引用 10 楼 xuejie09242 的回复:]
如果你开发一人并发用户每秒10000以上的网站,TB级数据库时呢?当你的Server有着几十个CPU,上百G的内存却还是反应迟缓呢?
你所说的性能不重要,只是用在性能不重要,或者说用大牛拉小车的情形,不客气讲,是对硬件资源的浪费,呵呵。
[/Quote]
ORM != 性能低下

[Quote=引用 10 楼 xuejie09242 的回复:]
国外的什么样的程序员吃香,或者是好的顶尖的程序员,是一味地学接口的程序员吗?这些,你懂吗?
[/Quote]
当然不是一味地学接口的程序员,善于利用工具是必须的。

[Quote=引用 10 楼 xuejie09242 的回复:]
这样的框架,远没有一个直接能够产生常用SQL的自动代码框架,可以生成SQL代码,也可以生成N层结构框架代码,现在已经不少这样的工具,用这样的工具才是真正的提高效率。
[/Quote]
天啦,我曾经看到一个朋友给我看到他用所谓的三层代码生成工具生成的代码,那简直让我吐血,层与层之间完全耦合在一起,明明一个类可以搞定的代码,非要分成3个文件来构造所谓的三层。
这样的代码完全脱离的分层的本意。
如果代码生成有那么好的话,那就不会有那么多人用nhibernate, Castle里面的ActiveRecord了, EF只是另外的一种选择。



xuejie09242 2009-06-12
  • 打赏
  • 举报
回复
[Quote=引用 7 楼 mapserver 的回复:]
可伶的lz,可笑的lz。

SELECT VALUE u FROM Entities.User AS u WHERE u.UserName LIKE '%AAA%';

SELECT * FROM [User] AS u WHERE u.UserName LIKE '%AAA%';

差别很大吗?

ORM的精髓lz懂吗?Linq to Object的精髓懂吗?

现在性能已经不是第一位考虑的,开发效率、可维护性才是第一位考虑的。在国外程序员一个人月的Money,足够买台服务器,这些lz你懂吗?
[/Quote]

请问,我有一个轻量级框架,可以自动生成SQL代码,读取数据库结构自动生成多层代码,可以是简单三层,Web service等方式,这就难维护吗?你据说的可维护性又在哪呢?
如果你开发一人并发用户每秒10000以上的网站,TB级数据库时呢?当你的Server有着几十个CPU,上百G的内存却还是反应迟缓呢?
你所说的性能不重要,只是用在性能不重要,或者说用大牛拉小车的情形,不客气讲,是对硬件资源的浪费,呵呵。

最后一个问题,你说国外的程序员怎样,1)你是国外的程序员吗?2)国外(如美国)挣的美元,对应到国内的水平,差不多是直接改成人民币,这你知道吗?3)国外的什么样的程序员吃香,或者是好的顶尖的程序员,是一味地学接口的程序员吗?这些,你懂吗?
xuejie09242 2009-06-12
  • 打赏
  • 举报
回复
EF是个框架,只是个人觉得这个框架过于庞大了,没必要再增加什么ESQL语言的。相当于我们学了ESQL语言,然后经过这个框架,再翻译成SQL,中间多了许多,没必要的。如果是个轻量级的框架,也许我会用。
xuejie09242 2009-06-12
  • 打赏
  • 举报
回复
也许有人误解我的意思了,EF作为一个框架,还是值得研究一下的,里面有很多东西值得我们去学习和研究,但这和用与不用它是两个概念,用这个框架,不如自己做个小巧的框架,能够自动生成SQL语句,自动生成三层框架,比这个不是好吗?好理解,也好掌握。简单就是美,不是吗!?
为什么要搞这么多,还要学和SQL差不多的语言,C#,SQL,ESQL,等待,总是跟着别人的脚步走,却忘记了自己要做做什么,要实现的功能,这才是我想要说的。
mapserver 2009-06-12
  • 打赏
  • 举报
回复
可伶的lz,可笑的lz。

SELECT VALUE u FROM Entities.User AS u WHERE u.UserName LIKE '%AAA%';

SELECT * FROM [User] AS u WHERE u.UserName LIKE '%AAA%';

差别很大吗?

ORM的精髓lz懂吗?Linq to Object的精髓懂吗?

现在性能已经不是第一位考虑的,开发效率、可维护性才是第一位考虑的。在国外程序员一个人月的Money,足够买台服务器,这些lz你懂吗?
outou 2009-06-12
  • 打赏
  • 举报
回复
LZ说的太对了。

7,763

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 非技术区
社区管理员
  • 非技术区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧