竟
然64個(gè)annotation，沒有分類，放在同一個(gè)package下，同一個(gè)package（javax.persistance）還有其他java文
件，共有88個(gè)java文件。不看內(nèi)容本身，單從表面，都覺得這是混亂不堪的事情。這是那個(gè)豬頭的杰作？glassfish上下載的源碼中，這些java
文件似乎都沒有author，估計(jì)也不好意思把名字放出來見人吧！
------
覺得對象關(guān)系存儲(chǔ)方面一直沒有突破，也沒有好的產(chǎn)品出來，其中一個(gè)原因，就是從沒有過優(yōu)秀的工程師投身過這個(gè)領(lǐng)域。關(guān)系數(shù)據(jù)庫為什么能夠一直堅(jiān)守領(lǐng)地，成為絕大多數(shù)商業(yè)應(yīng)用的基石，其中一個(gè)原因就是有過大量的精英投身于此，包括兩個(gè)圖靈獎(jiǎng)獲得者。
關(guān)
系數(shù)據(jù)庫，為了描述關(guān)系，創(chuàng)造一門SQL語言，將關(guān)系一些操作，例如投影（select）、選擇（where）、分組(group
by)等等，抽象得形象易懂，功能強(qiáng)大。對于數(shù)據(jù)的操作，SQL語言是最強(qiáng)大，也是最方便的，也是最易于使用的。一些非程序員的IT從業(yè)人員，非計(jì)算機(jī)專
業(yè)的人員都能夠熟練掌握SQL。
OO和Relational都是偉大的技術(shù)，從計(jì)算機(jī)最高榮譽(yù)獎(jiǎng)可以看出這兩個(gè)技術(shù)的偉大。OO的圖靈獎(jiǎng)獲得者是三個(gè)，Relational的圖靈獎(jiǎng)獲得者是兩個(gè)。
面向?qū)ο蠹夹g(shù)自1967年simula引進(jìn)以來，所想披靡，93年-98年從C++開始流行，然后到Java，成為主流編程技術(shù)。Relational沒有OO那么輝煌，但是在數(shù)據(jù)存儲(chǔ)方面的地位固如磐石，長期占據(jù)絕對的地位。
曾
經(jīng)OO技術(shù)涉足于數(shù)據(jù)存儲(chǔ)領(lǐng)域，但終究沒有成功。面向?qū)ο髷?shù)據(jù)庫的變現(xiàn)總是差強(qiáng)人意，面向?qū)ο蟮姆绞讲僮鲾?shù)據(jù)，總是不如使用關(guān)系那么方便，那么靈活，那么
易于使用，那么好的性能。于是人們在數(shù)據(jù)存儲(chǔ)和處理方面，不在青睞面向?qū)ο蠹夹g(shù)，而是仍然使用關(guān)系方式，使用SQL語言，使用關(guān)系運(yùn)算操作數(shù)據(jù)。面向?qū)ο?
數(shù)據(jù)庫成了曇花一現(xiàn)的東西，并且可能永遠(yuǎn)都不會(huì)再流行了。
OO成了主流編程技術(shù)，Relational占據(jù)了絕對的數(shù)據(jù)存儲(chǔ)地位，這兩大技術(shù)需要交互，需要橋接，這需要OR-Mapping。Relational雖然好，但我們也要與時(shí)俱進(jìn)，所以也需要OR-Mapping。
但
是，做OR-Mapping時(shí)，不積極吸取relational方式對數(shù)據(jù)處理的靈活性、方便性、簡單性，而只強(qiáng)調(diào)Relational和對象之間的的
Mapping，試圖以面向?qū)ο蟮姆绞讲僮鲾?shù)據(jù)，這是錯(cuò)誤的方向。以前的EJB、現(xiàn)在Hibernate、JPA都犯了同樣的錯(cuò)誤，試圖以更面向?qū)ο蟮姆?
式操作數(shù)據(jù)，從而導(dǎo)致復(fù)雜混亂的模型，這也是JPA的現(xiàn)狀吧。例如user.getGroup()，目前的ORM試圖以純OO的方式操作數(shù)據(jù)，所引起的
LazyLoad、n+1等問題，使得事情變得復(fù)雜而且混亂不堪。
一些開發(fā)人員，去學(xué)習(xí)Hibernate，不學(xué)習(xí)SQL，有人提倡，只需要了解面向?qū)ο缶幊碳夹g(shù)，不需要了解關(guān)系技術(shù)，亦屬于本末倒置。需求人員都會(huì)用的SQL語言，對數(shù)據(jù)操作最方便最簡單最強(qiáng)大的SQL語言，竟然成了令人生畏的紙老虎，可笑啊。
-------------
以下是過去的一些業(yè)界浮躁不理智：
1、面向?qū)ο髷?shù)據(jù)庫。曾被熱衷而吹捧，面向?qū)ο髷?shù)據(jù)庫的變現(xiàn)總是差強(qiáng)人意，面向?qū)ο蟮姆绞讲僮鲾?shù)據(jù)，總是不如使用關(guān)系那么方便，那么靈活，那么易于使用，那么好的性能。于是人們在數(shù)據(jù)存儲(chǔ)和處
理方面，不在青睞面向?qū)ο蠹夹g(shù)，而是仍然使用關(guān)系方式，使用SQL語言，使用關(guān)系運(yùn)算操作數(shù)據(jù)。面向?qū)ο髷?shù)據(jù)庫成了曇花一現(xiàn)的東西，并且可能永遠(yuǎn)都不會(huì)再
流行了。
2、
JDO投票鬧劇。2004-2005年，JDO的JSR在JCP投票被否決的，無聊者在Java社區(qū)以及媒體發(fā)起鬧事，陰謀論其為政治謀殺，幾大公司是的
迫于形象，重新投票使得JDO被通過，但JDO這種靜態(tài)AOP叫雕蟲小計(jì)式技術(shù)，不單開發(fā)過程不方便，而且會(huì)使得"enhance"之后的代碼不可調(diào)試。
這完全是對開發(fā)者不友好的技術(shù)，沒有前途的技術(shù)，竟然會(huì)有人為它在JCP投票不通過鳴不平。這件事情使得我更堅(jiān)信一點(diǎn)，不要相信那些技術(shù)編輯的判斷力。
3、
AOP。也是最近這幾年流行的一個(gè)名詞了。起了一個(gè)和OOP相似的名字，但是和偉大的OOP相比，它完全不算是什么。AOP只是一種很小很小的技巧而已，
靜態(tài)的AOP是黑客式的插入代碼，會(huì)導(dǎo)致代碼不可調(diào)試，動(dòng)態(tài)的AOP能力有限，AOP最常被引用例子“日志AOP”是不合適，有用的日志通常是精心設(shè)計(jì)
的，AOP方式的日志在生產(chǎn)環(huán)境中基本上是不可用。OO這么多年，這么為偉大，人們總是希望自己能做點(diǎn)什么和偉大的OO相比，于是命名為AOP，這是一個(gè)
可笑的名字，前些年還有人談?wù)撁嫦驅(qū)ο蟮奈磥硎敲嫦蚴聦?shí)，也是同樣的可笑。AOP有價(jià)值，但它是一種小技巧，和名字不般配。
--------------
目前在流行，但是可能是不理智的技術(shù)：
1、hibernate之類的ORM，試圖以面向?qū)ο蠓绞讲僮鲾?shù)據(jù)，和面向?qū)ο髷?shù)據(jù)庫一樣，重蹈覆轍。
2、Ruby，一個(gè)小腳本語言，只是因?yàn)閯?dòng)態(tài)類型、mixin之類的功能，還沒有被證明有生產(chǎn)力，有效益可用的腳本語言，就被媒體吹到天上去。Ruby有價(jià)值，但是最終結(jié)果會(huì)離大家的期待相差甚遠(yuǎn)。