Posted on 2006-01-12 00:39
非鱼 阅读(3240)
评论(3) 编辑 收藏 所属分类:
面向对象设计
我对RAD不感兴趣。因为RAD提供了太多的东西，而其中我会用到的大概不超过20%，其余的80%包括了我不想要的功能、BUG和杂乱的生成代码。就象
一个人只能吃一碗饭，RAD给了他两碗；如果真的是饭还好说，大不了放到馊掉或者倒掉，可惜RAD总是强迫你吃下去。
我对ORM也是这样的看法。
所有人对ORM都有一个简单的印象：减少对象持久化过程中的编码。不管使用什么方式，所有ORM工具都做到了这一点，但这似乎还不能满足我们的要求。
我们会怎样处理持久化对象呢？基本上是下列情况：
- 找到感兴趣的对象集；
- 查看这个集合中所有对象的部分信息，或者
- 查看特定对象的全部信息，或者
- 查看特定对象的部分信息，或者
- 处理特定对象或对象集合的全部信息，或者
- 处理特定对象或对象集合的部分信息；
- 把处理过的对象保存到数据库中。
在上面这些情况中，很少会用到一个对象的全部信息，多数情况下，我们只会使用、更新一个对象的部分信息。通常我们会这样说：“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的本份，我只是想它更灵活一点。抛砖引玉，想听听大家的想法。