潜鱼在渊

Concentrating on Architectures.

posts - 77, comments - 309, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

On Demand ORM

Posted on 2006-01-12 00:39 非鱼 阅读(3052) 评论(3)  编辑  收藏 所属分类: 面向对象设计
    我对RAD不感兴趣。因为RAD提供了太多的东西,而其中我会用到的大概不超过20%,其余的80%包括了我不想要的功能、BUG和杂乱的生成代码。就象 一个人只能吃一碗饭,RAD给了他两碗;如果真的是饭还好说,大不了放到馊掉或者倒掉,可惜RAD总是强迫你吃下去。

    我对ORM也是这样的看法。

    所有人对ORM都有一个简单的印象:减少对象持久化过程中的编码。不管使用什么方式,所有ORM工具都做到了这一点,但这似乎还不能满足我们的要求。

    我们会怎样处理持久化对象呢?基本上是下列情况:

  1. 找到感兴趣的对象集;
  2. 查看这个集合中所有对象的部分信息,或者
  3. 查看特定对象的全部信息,或者
  4. 查看特定对象的部分信息,或者
  5. 处理特定对象或对象集合的全部信息,或者
  6. 处理特定对象或对象集合的部分信息;
  7. 把处理过的对象保存到数据库中。
    在上面这些情况中,很少会用到一个对象的全部信息,多数情况下,我们只会使用、更新一个对象的部分信息。通常我们会这样说:“ORM,我需要一个对象,但 是我只关心这个对象中的FIELD1,FIELD2,FIELD5的信息。”实际上我们希望象使用SQL语句一样来使用ORM。例如在一个典型的使用工作流的环境中,每个环节一般只会用到对象的一部分信息。

    对象和关系数据库对信息的组织方式是不同的。对象的粒度可能会比数据库的记录要细,数据库基于效率考虑,可能会把信息集中存储。一些直接映射表记录到对象的ORM在这里可能会遇到麻烦。

    ORM的实现者总是考虑提供完整的对象,而习惯于SQL语句的开发者又希望得到自己请求的结果——可能是一个对象的部分信息。尽管LAZY LOAD也有很大的帮助,但开发者更想它能够LAZY到任意字段级别。

    在受益于ORM的简化数据库访问的同时,我们不希望ORM给我们带来性能方面的影响。这种恐惧时刻存在于我们心中:万一将来发生性能问题,我们如何象优化 SQL一样来优化ORM?更进一步想,如何在应用规模逐渐膨胀的情况下,有效的管理使用ORM的应用的可修改性?如何在负载递增的情况下保证使用ORM的 应用的可伸缩性?当在项目的后期发现一个具有侵入性的ORM不能再适应应用的规模和可伸缩性要求时,恐怕没有人 不头痛吧?

    我想要的ORM是一个On Demand ORM。就象下面这样写代码:

 1 public void mthod1() {
 2   User user = ODORM.request("name;password""pk=test");
 3   List groups = ODORM.requestList(Group.class,   "groupid;groupname""groupname like 'test%'");
 4   // after end user set the user groups
 5   user.setGroups(groups);
 6   ODORM.save(user);
 7   // sometimes do some more process.
 8   if ()
 9   method2(user);
10 }
11 
12 public void method2(User user) {
13   // securityLevel property should be loaded on   demand by ODORM mechanism.      
14   user.setSecurityLevel(user.getSecurityLevel()+1);    
15   ODORM.save(user);
16 }

    自然管理MAPPING是ORM的本份,我只是想它更灵活一点。抛砖引玉,想听听大家的想法。

评论

# re: On Demand ORM  回复  更多评论   

2006-01-12 01:56 by 郁也风
最近也在考虑mapping工具选型,本来是倾向于hiberante,不过随着考虑的深入,反倒越来越倾向于ibaties了。

对我来说,以下几点需要考虑:
1、入门台阶。相信每个项目负责人都不喜欢搞些难度较大的技术在自己项目中折磨那些新人;
2、历史项目。我们都知道的一点是hibernate的实现模式导致它在历史项目中的引入极为困难(新版是否在这方面有所增强,不太了解);
3、技术选型的稳定性。对于开源项目或是大家的练手项目来说,什么新就用什么,但对于一个公司的项目选型则关系较大,因为涉及到将来很长一段时间在公司的应用推广培训;
4、非鱼同志上面说的那些。

# re: On Demand ORM  回复  更多评论   

2006-01-12 09:45 by GHawk
越是需要操作的灵活性,对象映射的对象性自然就会下降。这样倒不如不用ORM,直接写JDBC和SQL,但是这对整个系统的架构会产生很大的影响。要指望Mapping和持久层没有性能损失是做不到的。就像吃海鲜,你越是要新鲜的海鲜,就越要放弃复杂的加工和运输手段。这个问题的解决可能不是ORM能够胜任的,或许更大程度上依赖于数据库系统。
软件设计是一种trade-off,技术本身没有优劣之分。工程师所要做的就是如何把各种技术融合到一起。性能或是对象性操作的获得也遵循这一原则。

# re: On Demand ORM  回复  更多评论   

2006-03-10 18:04 by gchhua
软件设计确实是trade-off,只存在合适与否,不存在优劣。就如模式的一个重要条件:适用的上下文

只有注册用户登录后才能发表评论。


网站导航: