Posted on 2006-01-12 00:39
非魚 閱讀(3251)
評論(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的本份，我只是想它更靈活一點。拋磚引玉，想聽聽大家的想法。