ADO.NET完成的hibernate没有完成的事情

ORM只是对象化，层次化，像这种一个DATASEt穿越历史时空完成所有层的串挂完全失去层次感，所有的层都糅合在一起，不便于抽象而且和底层联系太紧密，这个注重的是一些小技巧满足多层的需要，而ORM把数据访问层抽象了一下，隔离了数据库，可以完全分工，整个项目的层次也就出来，便于数据组件化，长期用DATASET的人当然不能理解其中的奥妙，另外长期面向SQL编程的人根本就没有对象的概念更不会区分所谓SET/GET类型的对象，这种是一种简单的数据封装，也是面向对象的封装特性体现，所以说无知者无畏，很正确，没有理解之前还是虚心学习，不要动不动就批判。

另外完成需求即可得人，只能给公司留下一大堆麻烦，这种人公司要了也没有用，因为软件是有生命的，需求是变化，后期维护比前期开发更重要，一个不能维护的软件生命周期就太短了，可能半个月都用不上就需要天天在一堆SQL中穿梭，如果前期开发的人走了，接手的人就更麻烦了，一大堆SQL怎么看都看不过来。

另外可以说.NET阵营天生就没有OOP的思想。

只是换个面向对象的语言写面向过程的程序，仅此而已

整个.NET语言都是模范JAVA，你又有什么不服气的呢，.NET要赶上JAVA不光要借租.HIBERNATE,SPRING，还有很多路要走

另外像电信，银行都是用JAVA开发，不要说1KW数据级JAVA，更多的也处理得了。

好好学习吧，自己完成不了的不代表别人也完成不了。你还要好好的学习！！

可怜的 .NET版块
.net还是回家切菜的好 用来杀牛 怕是 不行

电信银行 传统都是j2ee架构，最近几年.net架构的项目也有一些。
海量数据处理，最依赖的还是硬件，然后是架构设计，跟具体语言无关。


c#和java是DNA的双链，螺旋上升，已经说不清谁抄袭谁了。
语言的特性不是哪个语言专有的

javaeye的域名害人不浅

和很挫的人说道理是会贬低自己的，如果oop的思想需要区分C#还是java，那这种垃圾程序员哪个公司收了哪个公司倒霉。

真的吗？ORM只不过是为了把二维关系表映射成面向对象的模型，真的是通过数据库自动生成可以把数据库设计放到最后吗？没有数据库设计何来所谓的ORM？何来*.hbm.xml? 在我看来，ORM只是一个ER模型到OO模型过渡的桥梁. 没有二维关系表,他甚至读不知道怎样自动生成。面向对象的方式思考是为了思考业务逻辑，不是思考数据库设计，而且更不能通过数据库自动生成可以把数据库设计放到最后。其实，OO最适合功能封装（focus在功能而不是数据），也就是为什么在设计时（特别是在用OOAD)我们强调接口（纯功能的）；而数据关系（最主要查询关系），实践证明二维关系表最为适合（关系代数）。如果真要先做OO能后再到ER设计(或是说通过数据库自动生成可以把数据库设计放到最后），这不是ORM工具或框架能办到的（她是ER->OO映射的，反过来，将要难得多多）。到目前为止，还从来没看到过这样的报告(best practices)。

ORM只是提供永久层功能生成的工具或框架,不能延迟数据库设计. 没有数据库设计,ORM将无用武之地. 个人觉得,ORM只是一个从RDBMS到ODBMS的过渡性方案,一旦ODBMS商业化成功,ORM也将退出舞台了. 到那时, 我们可以用完全面向对象的方式思考数据库设计了(但不是延后而应是同时). 但现在应该不行.

ODBMS 是个很好的方向。

orm的含义和名称一致，就是mapping，为什么mapping，为了实现与oop一致的使用方式。而不是为了设计数据库。~

我在银行写软件的时候，你还不知道在哪个高中读书呢？ 我们明明用的是C和CICS，你何来的“都是用java”？

信口开河。