在BS领域真有必要费那么大劲去用ORM么？

[eddiego]

在BS领域为什么大家都在流行用一大堆ORM ? nHibernate、LinQ、Entity Framework，加了什么实体层、数据层，但对于最终得到的IList我们还不是当做一个表来处理，一个 froeach(object a in DataSet)搞定。

如此还有必要这个劳心劳肺的把转换成对象么？增加开发难度与工作量不说，还降低了系统性能。。。直接一个DataTable不就行么？

当然也可能我的想法比较肤浅，所以欢迎朋友们来讨论一下这个问题，以解我心中疑惑

[honkerhero]

用datatable一般都是采用典型的Data+Manager模式吧，数据与操作分离
这一点恰恰与真正的面向对象有点冲突，因为Data是哑巴类，没有行为，跟书呆子一样

[moonshineidolon]

多看看设计吧

你就有收获了，也可以顺便评价 比较一下自己的开发水平。

[guoyichao]

ORM可以让程序开发者脱离sql的苦海，sql应该是dba学的东西，程序员没太大必要专门学db的sql，程序员只要掌握一种从关系型数据源取得数据的方法就足够了，linq就是ORM上的重大突破，通用化了所有关系数据源存取方法。

[honkerhero]

[Quote=引用 25 楼 guoyichao 的回复:]
ORM可以让程序开发者脱离sql的苦海，sql应该是dba学的东西，程序员没太大必要专门学db的sql，程序员只要掌握一种从关系型数据源取得数据的方法就足够了，linq就是ORM上的重大突破，通用化了所有关系数据源存取方法。
[/Quote]

不懂SQL的程序员，永远只能是junior

[sjt000]

[Quote=引用 18 楼 eddiego 的回复:]
当然ORM存在他的优点是肯定的，DataTable确实存在缺点，但由于BS表现层的特性，对象最终还是需要以数据的形式处理，在中型BS项目中ORM的利就真的大于弊么？
[/Quote]
你只看到了数据和其展现，如果按对象，封装操作和职责的时候，用DataTable绑定当然没问题了，但是如何向其封装操作呢？

[sjt000]

你如果主要功能就是把数据从库里取出来，在前台显示一下，那真的没必要～

[gp_ky]

学习

[w375893296]

看看


软件开发交流群 58773512 欢迎加入！！！！！

[Luck_cl]

那样的话，更方便维护，也减少了代码的重复量。

[eddiego]

[Quote=引用 20 楼 sjt000 的回复:]
你如果主要功能就是把数据从库里取出来，在前台显示一下，那真的没必要～
[/Quote]

网站基本上就是干这个事儿

[java_renyusheng]

用或不用只是一种选择，没有人说必须要用，这个也没有什么好争论的

等你需要的时候自然会知道它的好处

你现在做的东西我想一定没有复杂或庞大到一定的程度

[java_renyusheng]

还有orm复杂吗，没感觉出来，如果是入门，我想一天就够了

[Roc_Lee]

对象对象，根本是对象，方便为主。这些也就是方便

[eddiego]

[Quote=引用 30 楼 java_renyusheng 的回复:]
还有orm复杂吗，没感觉出来，如果是入门，我想一天就够了
[/Quote]
学习并不复杂，无非是数据库到对象的一个转换，但是有必要么？你们总是说概念，一切都是对象，我当然明白
这个道理，但是，在BS领域其　实用性倒底有多少优势？

你把一个DataTable转换成对象，又马上要用DataList把它在Html中显示出来，这中间基本上没有发挥出对象的
优势。

所以我的根本问题是：orm得到对象之后，这个对象在网站中能起到多少便利作用？？？？？

[eddiego]

注意，我是指网站。。。。不是其它领域的开发

[hecker728]

弱弱的文一下，，你们说的orm，，相当于ＪＡＶＡ中的ＢＥＡＮ么。
就是把数据库中的表专门实例化一个类，，是这样么？？

[行云边]

orm 使程序的结构更加清晰,orm把应用层跟数据层分割开,这样就跟数据库解耦合了.如果程序设计的好不管数据库是什么类型 mysql 还是 sqlserver(linq), 甚至数据表的变化或者字段的变化不需要重新编译系统,只要修改配置文件即可.而且维护也变的简单. 当然如果你程序的业务逻辑比较简单,那完全没必要使用orm,因为使用orm性能会打折扣.特别是那些需要频繁操作数据库的业务.

[fengjing0919]

真是无意中看到这个帖子。
其实面向对象，面向接口，一定要用这些东西架构工程楼主感到了疑惑。
因为过程开发带来的维护弊端，必须要有一些方式去解决。大型项目如果真的只是独立的写SQl，你会陷入SQl地狱，假如数据库有一处字段修改，你都要针对所有的SQL去修改，你会发现自己疯掉了。

解开这些紧密的耦合，为了未来有个相对轻松的修改和维护。减少修正带来的bug等。

[Quote=引用 26 楼 honkerhero 的回复:]
引用 25 楼 guoyichao 的回复:
ORM可以让程序开发者脱离sql的苦海，sql应该是dba学的东西，程序员没太大必要专门学db的sql，程序员只要掌握一种从关系型数据源取得数据的方法就足够了，linq就是ORM上的重大突破，通用化了所有关系数据源存取方法。


不懂SQL的程序员，永远只能是junior
[/Quote]

我并不赞同，程序员只要关心逻辑就好了，这是程序员真正该去做的事情。

好坏程序员的区分，不是功能是否完成，而是在于程序完成后的可维护性和扩展性。

[WQ771211]

ORM在使用时，POJO类和最基本的CURD操作一定要依据配置文件(如xml）自动生成，如果还要手工生成POJOs，就毫无意义了。

只有比较个性化的操作，才需要动用程序员。这点和使用DataTable是一致的，使用DataTable，也要直接根据xml配置，自动完成基本的CURD

ORM是否强大，取决于对SQL的支持，因为SQL是多变的，可能有多个表的嵌套查询，多个表的JOIN，还有GROUP BY、ORDER BY、WHERE等，这些东西不是一个简单的一对多、多对多能描述清楚的，而且效率也很关键，xxxQL如果转化为SQL时产生大量垃圾代码的话，会直接把系统拖垮

相比DataTable，ORM组件还能支持事务处理，也是重要的特性

希望.net平台也出台像JPA那样的规范，ORM产品又多又乱对程序员很不利

[WQ771211]

另外POJOs的个性化操作(除CURD,getter,setter之外的)，最好用AOP切入，而不要在POJO里面加代码，加观察者
-----------------------------------
.net这方面还是不如java成熟，所以借用了一点java的概念