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

    最近在做.NET平台上C#+SPRING.NET+Nhibernate的开发，之前一直在做.NET+SQL SERVER2005的开发，这里对比两者的差异，发表一些观点
    不管我们用的是hibernate还是nhibernate，在从数据库返回了数据之后，我们总是需要自己去构建模型层。不可否认，自己构建模型层的结构，确实更大程度上的把开发的主动权控制在了我们程序员的手中，但是由此带来的不便也是显而易见的。如果我们使用ADO.NET，那么我们在处理返回的dataset的时候，其已经对里面的datatable构建好了。省去了我们对模型层字段的设置和配置，我们只需要知道数据库返回的是什么字段，在做数据绑定的时候，对应这个字段就行了。对字段的类型所关心的很少，我们有更多的时间来关心业务上的问题。
    但是，当我们用Nhibernate的时候，模型层需要我们自己去构建domain和dto，这个本身就花费了我们大部分的时间。而且我从网上查了一些资料，其实nhibernate的实际效率并不比dataset要高哪里去。如果说仅仅是内存上的多占用的那部分，我相信这点内存我们还是支付的起的。但是，hibernate思维方式带给我们的麻烦事情还远没有结束。每当存储过程改变的时候，也就是从数据库返回的数据集的字段有所改变的时候，我们这个时候需要做的不仅仅是需要改变页面表现层的字段名，而且还要动domain或是dto的字段设置，尤其是字段类型。这些都是相当繁琐，而且增加了程序员犯错的机会，降低了开发的速度。
    不可否认，MS把这些东西都给我们封装的太完美了，而完美如果非要说“挣脱MS的枷锁，做自己开发的主人”这种话，什么都自己去做的话，也是会付出很大的代价的。别人有好的东西，我们还是应该承认。
    抛砖引玉。

评论

36 楼 egmkang 2009-04-05  

风花雪月饼 写道

先声明，我不是.Net程序员，但是我看过一些书。

.Net的主流设计方式是表模型。
微软在这个上面花了很多精力。
并且这种设计方式在很多Java系统中存在。
事实证明其存在也是有意义的。

什么ORM什么乱七八糟的。还JDBC。。。.Net哪给你JDBC这么落后的玩意。

楼主，如果做.Net，按微软的提倡的方式即可，没必要扯到Java这摊浑水里面去给自己制造麻烦。
楼上那些ORM和OOD,OOA的家伙可以无视了。只要你能用简便的方式来解决问题就好。

兄弟,我也是.NET程序员.....怎么我感觉你说的话很怪异,跟没编过程人说出来的一样

35 楼 kimmking 2009-04-04  

xiao_Yao 写道

ray_linn 写道

kimmking 写道

xiao_Yao 写道

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

javaeye的域名害人不浅

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

其实 我说的意思是 谁适合用在什么地方，就用谁
至于谁高谁底何必争执，

我作为 写java习惯了的人，自然不会满口称赞你.net如何如何高明。
也不会去从什么思想高度去评判哪个高哪个底。

ls的说话跟放p看来没啥区别，大家无视吧~~

34 楼 xiao_Yao 2009-04-04  

ray_linn 写道

kimmking 写道

xiao_Yao 写道

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

javaeye的域名害人不浅

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

其实 我说的意思是 谁适合用在什么地方，就用谁
至于谁高谁底何必争执，

我作为 写java习惯了的人，自然不会满口称赞你.net如何如何高明。
也不会去从什么思想高度去评判哪个高哪个底。

33 楼 chandler 2009-04-01  

    一个新手的观点吧。不了解.net。只会一点点java.
    怎么说呢，持久层框架，hibernate的作用只是使得你查询语句之后的结果是对象，而不是基本数据类型。省去一点把基本数据转换成对象的操作而已。顺带解决了一点缓存管理。

32 楼 siye1982 2009-04-01  

是Nhibernate,不是hibernate.

31 楼 mathgl 2009-03-31  

kimmking 写道

ray_linn 写道

qqggcc 写道

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

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

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

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

信口开河。

偶现在还是xx银行，现在所有银行的核心业务还是c~~

外围才是j2ee~ .net~~

貌似用 pro c多。

30 楼 kimmking 2009-03-31  

ray_linn 写道

qqggcc 写道

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

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

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

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

信口开河。

偶现在还是xx银行，现在所有银行的核心业务还是c~~

外围才是j2ee~ .net~~

29 楼 ray_linn 2009-03-31  

qqggcc 写道

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

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

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

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

信口开河。

28 楼 kimmking 2009-03-31  

jok 写道

魔力猫咪 写道

ORM是为了更好的面向对象。ORM减轻了你对JDBC的封装。面向对象是为了什么？为了更好的维护。
ORM的优势是你可以用完全面向对象的方式思考。通过数据库自动生成可以把数据库设计放到最后。避免因为早期数据库设计不合理造成后期难以改动。
缓存和ORM没任何直接关系。现在的ORM帮我们封装了缓存调用，但是你JDBC也可以用缓存。
面向数据库和面向对象比，我没感到优势。如果是简单的项目，那面向对象可以通过ORM做得更加简单。复杂的就不用说了，二维关系表在表示复杂关系方面很难，到处是关联表，不利于人的理解。

真的吗？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一致的使用方式。而不是为了设计数据库。~

27 楼 jok 2009-03-31  

魔力猫咪 写道

ORM是为了更好的面向对象。ORM减轻了你对JDBC的封装。面向对象是为了什么？为了更好的维护。
ORM的优势是你可以用完全面向对象的方式思考。通过数据库自动生成可以把数据库设计放到最后。避免因为早期数据库设计不合理造成后期难以改动。
缓存和ORM没任何直接关系。现在的ORM帮我们封装了缓存调用，但是你JDBC也可以用缓存。
面向数据库和面向对象比，我没感到优势。如果是简单的项目，那面向对象可以通过ORM做得更加简单。复杂的就不用说了，二维关系表在表示复杂关系方面很难，到处是关联表，不利于人的理解。

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

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

26 楼 ray_linn 2009-03-29  

kimmking 写道

xiao_Yao 写道

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

javaeye的域名害人不浅

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

25 楼 kimmking 2009-03-29  

xiao_Yao 写道

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

javaeye的域名害人不浅

24 楼 kimmking 2009-03-29  

qqggcc 写道

subwayline13 写道

魔力猫咪 写道

ORM是为了更好的面向对象。ORM减轻了你对JDBC的封装。面向对象是为了什么？为了更好的维护。
ORM的优势是你可以用完全面向对象的方式思考。通过数据库自动生成可以把数据库设计放到最后。避免因为早期数据库设计不合理造成后期难以改动。
缓存和ORM没任何直接关系。现在的ORM帮我们封装了缓存调用，但是你JDBC也可以用缓存。
面向数据库和面向对象比，我没感到优势。如果是简单的项目，那面向对象可以通过ORM做得更加简单。复杂的就不用说了，二维关系表在表示复杂关系方面很难，到处是关联表，不利于人的理解。

兄弟你处理过1000W以上的数据吗？OOP是你的信仰，我尊重好了，但是这个世界上还有其他的语言和思想，比如erlang。
唉.NET版块讨论JDBC，真让人沮丧。

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

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

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

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


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

23 楼 xiao_Yao 2009-03-29  

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

22 楼 qqggcc 2009-03-29  

subwayline13 写道

魔力猫咪 写道

ORM是为了更好的面向对象。ORM减轻了你对JDBC的封装。面向对象是为了什么？为了更好的维护。
ORM的优势是你可以用完全面向对象的方式思考。通过数据库自动生成可以把数据库设计放到最后。避免因为早期数据库设计不合理造成后期难以改动。
缓存和ORM没任何直接关系。现在的ORM帮我们封装了缓存调用，但是你JDBC也可以用缓存。
面向数据库和面向对象比，我没感到优势。如果是简单的项目，那面向对象可以通过ORM做得更加简单。复杂的就不用说了，二维关系表在表示复杂关系方面很难，到处是关联表，不利于人的理解。

兄弟你处理过1000W以上的数据吗？OOP是你的信仰，我尊重好了，但是这个世界上还有其他的语言和思想，比如erlang。
唉.NET版块讨论JDBC，真让人沮丧。

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

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

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

21 楼 qqggcc 2009-03-29  

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

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

20 楼 qqggcc 2009-03-29  

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

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

19 楼 hejianhuacn 2009-03-25  

能实现需求第一

18 楼 llade 2009-03-24  

gloomyd 写道

技术没有好坏之分
只要适应你的需求，并且有一定的预见性的满足期需求即可

不要成天的DDD OO挂在嘴边
只要最适合我的，就是最好的。  拜托大家以一种宽容点的心态看待问题

让我想起佛家的名言：“菩提本无树，明镜亦非台。本来无一物，何处惹尘埃。”，善哉善哉。

17 楼 gloomyd 2009-03-24  

技术没有好坏之分
只要适应你的需求，并且有一定的预见性的满足期需求即可

不要成天的DDD OO挂在嘴边
只要最适合我的，就是最好的。  拜托大家以一种宽容点的心态看待问题