關(guān)于個(gè)人文檔管理 － 電子書2

上一篇文章里面說(shuō)到，手里的電子書，大體可以分成經(jīng)典、手冊(cè)、喜歡的、教材、普通的書、消遣、難懂的書、別人推薦的書、騙人的書這么幾個(gè)類別。

那么針對(duì)這幾個(gè)類別該怎么區(qū)別對(duì)待呢？

1、對(duì)于經(jīng)典的、手冊(cè)類型的書：對(duì)于這種經(jīng)常會(huì)用到，而且極有價(jià)值的書，要放到最容易獲得的地方。通常每個(gè)人的這種書都不多。把它們管理好（后面會(huì)說(shuō)怎么管理）后，做一個(gè)鏈接放到桌面上或者桌面上的文件夾里?！?dāng)然，在Mac下還有更好的方式，不過(guò)在Windows和Linux下，按上面的方式來(lái)做就足夠了

2、對(duì)于經(jīng)常喜歡看的、消遣的書：如果可能，放到手機(jī)、MP3里面吧。那樣你就什么時(shí)候都能看了。呵呵。

3、對(duì)于教材、普通的書：分門別類的管理好。給你正在看的書建個(gè)鏈接放到桌面上?？赐炅嗽趺刺幚砗竺嬖僬f(shuō)

4、對(duì)于難懂的和別人推薦的書：扔掉它吧。再好的書，不看也是垃圾一堆。不要擔(dān)心你可能會(huì)有真正想讀的時(shí)候，一般來(lái)說(shuō)，技術(shù)類書籍，你現(xiàn)在不想讀，你永遠(yuǎn)都不會(huì)想讀的。而且，如果是經(jīng)典的話，你想讀的時(shí)候自然會(huì)找得到。

好了。有了上面的對(duì)電子書區(qū)別對(duì)待的前提后，我們來(lái)開(kāi)始討論如何在計(jì)算機(jī)上管理電子書吧。

首先，我要先說(shuō)一說(shuō)我認(rèn)為電子書管理中最重要的兩個(gè)前提：
1、CPU的時(shí)鐘周期不值錢，你的時(shí)間值錢。
2、硬盤的容量不值錢，你的大腦容量值錢。

有了這兩個(gè)前提，就可以說(shuō)說(shuō)我在電子書管理方面的經(jīng)驗(yàn)啦。我的經(jīng)驗(yàn)大體如下：
1、不要建立過(guò)多、過(guò)深的文件夾：
一般來(lái)說(shuō)，除了該死的java程序，你的文件夾都不要建到5級(jí)以上。因?yàn)榧词姑總€(gè)文件夾里面只有兩個(gè)文件夾，你就會(huì)有32個(gè)文件夾。你的大腦容量是有限的，你不需要記住這些文件夾的，一般人也記不住。
你終究會(huì)發(fā)現(xiàn)，為了找到一個(gè)文件，你總是在不同的文件夾中跳躍。

2、集中管理：
不要告訴我你的文檔散布在多個(gè)分區(qū)（C:、D:、E:...）的多個(gè)文件夾下。相信我，那絕對(duì)是一個(gè)噩夢(mèng)。你可能會(huì)反駁我說(shuō)，我把所有的雞蛋都裝到了一個(gè)籃子中，會(huì)有風(fēng)險(xiǎn)。實(shí)際上，你只有一個(gè)文檔文件夾的話，備份和同步是一件非常容易的事情。

3、要搜，不要找：
當(dāng)你的文檔越來(lái)越多的時(shí)候，你就會(huì)發(fā)現(xiàn)在文檔文件夾里找到你想要的文檔是多么麻煩的一件事情了?，F(xiàn)在的操作系統(tǒng)都有可以進(jìn)行全文檢索的高性能搜索引擎了。畢竟機(jī)器要比肉眼精確，你的時(shí)間要比CPU的時(shí)鐘周期更值錢

4、利用元數(shù)據(jù)
在這一點(diǎn)上，Mac是做得最好的。它提供了Spotlight注釋這個(gè)完美的東西。你可以以注釋的方式來(lái)為文檔添加搜索的元數(shù)據(jù)。這也是我現(xiàn)在進(jìn)行電子書管理的精髓所在。Google Desktop好像沒(méi)有這個(gè)功能。

總結(jié)一下，通過(guò)在電子書管理的兩個(gè)前提下，靈活的使用鏈接、搜索的功能。是我管理電子書的手段。

我會(huì)在下一篇文章里，說(shuō)說(shuō)我管理電子書的方式。

posted @ 2008-09-01 14:37 guitarpoet 閱讀(564) | 評(píng)論 (0) | 編輯 收藏

關(guān)于個(gè)人文檔管理 － 電子書

posted @ 2008-08-31 17:46 guitarpoet 閱讀(931) | 評(píng)論 (2) | 編輯 收藏

關(guān)于個(gè)人文檔管理 - 電子郵件2

這是關(guān)于電子郵件管理的最后一篇。

我的郵件管理心得大概可以分成下面幾個(gè)點(diǎn)：

1、即看即管理：收到郵件之后，如果沒(méi)有處于不可打斷的狀態(tài)下，就要立即開(kāi)始處理，處理方式大概分成下面幾種
    *如果是無(wú)用的郵件，立即把它刪掉
    *如果郵件很長(zhǎng)，或者郵件中鏈接比較多（比如訂閱的期刊），而時(shí)間有限，把郵件設(shè)置成為未讀，留待有時(shí)間的時(shí)候讀
    *如果郵件跟工作有關(guān)，而沒(méi)有時(shí)間處理，給郵件打上旗標(biāo)，留待有時(shí)間的時(shí)候處理
2、周期性管理：每天都需要整理該天的郵件（這也是務(wù)必做到當(dāng)日事，當(dāng)日畢的工作態(tài)度），處理掉未讀的和加注旗標(biāo)的。對(duì)于期刊，未必一定要讀完。加注旗標(biāo)的工作，則需要進(jìn)行工作管理了。
3、階段性梳理：在到達(dá)階段性的時(shí)間點(diǎn)時(shí)（如一個(gè)項(xiàng)目結(jié)項(xiàng)，每個(gè)月的第一天或者最后一天）。需要對(duì)這一階段內(nèi)的工作和相關(guān)材料進(jìn)行梳理。電子郵件也是其中之一。
4、善用搜索：在充分的維護(hù)元數(shù)據(jù)之后，你就會(huì)發(fā)現(xiàn)搜索的好處了。比如，在你為項(xiàng)目干系人建立聯(lián)系人組之后。相關(guān)時(shí)間跨度內(nèi)的項(xiàng)目相關(guān)的郵件一個(gè)相關(guān)查詢就足夠了。如果你的郵件客戶端支持在查詢的結(jié)果上查詢的功能。通過(guò)聯(lián)系人、主題等等信息，一般說(shuō)來(lái)，找到你想找的郵件，不會(huì)非常困難。
5、保存常用的搜索：我有幾個(gè)常用的搜索，以智能文件夾的方式保存起來(lái)了。這些常用的搜索是：
    *To Read：所有的未讀郵件
    *Today：當(dāng)天收到的郵件
    *Flagged：所有加旗標(biāo)的郵件
    *Has Attachment：所有有附件的郵件
6、充分利用郵件客戶端的特色功能：有的郵件客戶端（如GMail和Apple Mail）都可以根據(jù)話題進(jìn)行郵件自動(dòng)分組。GMail的類似論壇帖子的方式是更加優(yōu)雅一些。按話題自動(dòng)分組郵件，可以極大的減輕利用郵件討論一件事情的負(fù)擔(dān)。尤其是在多人討論的時(shí)候。
7、充分利用郵件的處理規(guī)則：很多郵件的管理和處理都可以采用規(guī)則進(jìn)行自動(dòng)化的處理。比如，可以把所有來(lái)自家里人的郵件打上綠色的標(biāo)簽。便于和工作郵件區(qū)別開(kāi)來(lái)?；蛘甙严嚓P(guān)郵件拷貝到相關(guān)的文件夾中（GMail的對(duì)應(yīng)操作是為這個(gè)郵件打上標(biāo)簽）。
8、利用搜索引擎技術(shù)：不要用OutLook自帶的查找。那樣查找效率太低了。可以利用MSN Toolbar或者Google Desktop這種搜索工具來(lái)幫助你。我用的是Mac OSX，Spotlight已經(jīng)很好用了。

好了，關(guān)于電子郵件的管理，就說(shuō)到這么多吧。下一篇里，我將會(huì)討論電子書的管理。

posted @ 2008-08-25 21:57 guitarpoet 閱讀(396) | 評(píng)論 (0) | 編輯 收藏

關(guān)于個(gè)人文檔管理 - 電子郵件

好吧，我承認(rèn)，我的上一篇文章沒(méi)有提到跟電子郵件管理相關(guān)的事情。呵呵。

無(wú)論你使用什么郵件客戶端（GMail除外，GMail屬于比較奇怪的，待會(huì)兒再提）。郵件的管理操作都可以簡(jiǎn)單的看成是對(duì)只讀文件的操作。

郵件就是一個(gè)個(gè)的只讀郵件，你通過(guò)文件夾（可以分級(jí)——也就是文件夾套文件夾）來(lái)分類的管理它們。

你可以通過(guò)郵件的元數(shù)據(jù)（收件人、發(fā)件人、抄送、發(fā)送時(shí)間、接收時(shí)間、重要程度、是否已讀、所在郵箱、內(nèi)容。。。）來(lái)檢索、排列和查找郵件。

下面，我來(lái)列舉幾個(gè)我所見(jiàn)過(guò)的郵件管理方式（我在這里只列舉我所見(jiàn)到的方式，使用技巧打算在下一篇文章里寫）：

1、日期型：
這類的郵件管理方式，一個(gè)最大的特點(diǎn)就是每個(gè)月都建立一個(gè)新的文件夾。文件夾的名稱就是當(dāng)月的年份和月份，如2008-02。當(dāng)月收到的郵件都從收件箱中拷貝或者直接轉(zhuǎn)移到該文件夾中（這個(gè)規(guī)則應(yīng)該很好寫）。

以一天平均收到100封郵件的頻度來(lái)算（如果是普通工作郵件的話，已經(jīng)算是非常多了，以我的經(jīng)驗(yàn)來(lái)說(shuō)，平均一天20～50封是正常的）。在一個(gè)工作月內(nèi)，可以收到2200封郵件。在一個(gè)文件夾內(nèi)并不難管理（何況你還會(huì)刪掉一些無(wú)意義的郵件，并且還可以在這個(gè)基礎(chǔ)上進(jìn)行分組和過(guò)濾）。

如果你確實(shí)有精益求精的追求，你可以在這個(gè)文件夾下再分成工作細(xì)類。這樣看起來(lái)更漂亮。

這種管理方式很適合短期雜事很多的人（比如HR）。這種方式的優(yōu)點(diǎn)是，月底進(jìn)行個(gè)人統(tǒng)計(jì)的時(shí)候非常方便。而且做查詢也比較方便（直接用眼睛看）。

當(dāng)然，這種方式缺點(diǎn)也非常明顯。你肯定不能從一串?dāng)?shù)字上看出你這個(gè)月都干什么了（當(dāng)然你愿意在其下花力氣分成細(xì)類，這一點(diǎn)就容易一些）。對(duì)于經(jīng)常并行的進(jìn)行有時(shí)間跨度工作（比如多個(gè)項(xiàng)目的平臺(tái)技術(shù)支持）的人而言，這一管理方式明顯效率低下。

2、項(xiàng)目型：
即使是進(jìn)行項(xiàng)目型的管理，仍然需要通過(guò)時(shí)間來(lái)劃分郵件（為了歸檔和寫年終總結(jié)方便）。但是時(shí)間的劃分往往會(huì)比較長(zhǎng)，比如用一季度、半年或者一年來(lái)劃分。

項(xiàng)目型管理的最大特點(diǎn)就是按項(xiàng)目分組管理郵件。舉例來(lái)說(shuō)吧。

假設(shè)我是一個(gè)平臺(tái)軟件工程師，我支持著公司在廣東、山東、北京、上海這四個(gè)項(xiàng)目。

我會(huì)在今年（2008）的文件夾下建立四個(gè)文件夾分別是廣東電力、山東社保、北京移動(dòng)、上海聯(lián)通。我會(huì)在我的聯(lián)系人里建立這四個(gè)組。然后建立四個(gè)規(guī)則，把所有在收件箱中這四個(gè)組中聯(lián)系人發(fā)的郵件分別拷貝或者移動(dòng)到這四個(gè)文件夾中。

項(xiàng)目型的方式，適合于對(duì)多個(gè)項(xiàng)目（子項(xiàng)目）進(jìn)行并行工作的人。在項(xiàng)目相關(guān)的文件夾中可以通過(guò)基于時(shí)間的查詢查找到相應(yīng)的郵件?？梢院芤荒苛巳坏目闯瞿阍谀骋荒甓甲隽四男╉?xiàng)目。而且，通過(guò)按照時(shí)間的查詢，仍然可以查出你在某個(gè)月的工作郵件。

如果你的雜項(xiàng)工作很多或者大多數(shù)都是沒(méi)有規(guī)律的工作，這種方式就不一定合適。

3、區(qū)別對(duì)待型：
區(qū)別對(duì)待型的精髓，就是看人下菜碟。以我的經(jīng)驗(yàn)，在營(yíng)銷的人員中采用的比較多。不過(guò)也有技術(shù)人員采用。呵呵。

區(qū)別對(duì)待型就是按照聯(lián)系人的組來(lái)安排郵件。比如可以建這么幾個(gè)文件夾：領(lǐng)導(dǎo)、山東社保項(xiàng)目組、朋友、其他。

說(shuō)真的我沒(méi)看出來(lái)這種管理方式的優(yōu)點(diǎn)。我覺(jué)得這種方式跟沒(méi)管理沒(méi)啥區(qū)別。真的。

4、狀態(tài)分類型：
按照郵件所關(guān)聯(lián)的工作的狀態(tài)進(jìn)行分類?？梢苑殖桑捍k、正在處理、已經(jīng)處理、已經(jīng)延遲和其他幾個(gè)部分。

有的項(xiàng)目經(jīng)理是采用這種方式來(lái)管理郵件的。所有的未讀郵件都是待分類的郵件。之后通過(guò)手工揀選的方式來(lái)進(jìn)行管理。

這種方式，不是很便于存檔和查詢（試想，過(guò)了一段時(shí)間之后，已經(jīng)處理這個(gè)文件夾里面會(huì)有多少郵件？）。

總結(jié)一下：
1、郵件會(huì)越積越多的。相信我，真的會(huì)越積越多的
2、郵件對(duì)工作非常重要，所以郵件的歸檔、保存和檢索都非常重要
3、從目前的效果上看，郵件客戶端仍然無(wú)法被GMail的Ajax客戶端代替
4、最好要根據(jù)自己的工作性質(zhì)，決定出一個(gè)適合自己的郵件管理風(fēng)格。在這個(gè)基礎(chǔ)上還可以應(yīng)用很多的技巧。機(jī)器不怕重復(fù)，但是人都害怕復(fù)雜

好了，下一篇里，我將把我所知的郵件管理的技巧都寫出來(lái)。也作為一個(gè)存檔。留待以后接著完善吧。

另外，關(guān)于電子郵件寫得太多，未免開(kāi)始離題了。再寫一篇，就要開(kāi)始寫電子書/文檔的管理（我打算把這個(gè)方面重點(diǎn)寫一寫）了。

posted @ 2008-08-24 10:26 guitarpoet 閱讀(605) | 評(píng)論 (0) | 編輯 收藏

關(guān)于電子郵件

關(guān)于電子郵件

好了，今天來(lái)討論電子郵件。

電子郵件是非常優(yōu)雅和浪漫的交流方式——郵件的電子表示方式。它擁有前輩的很多優(yōu)點(diǎn)，在某些方面上甚至超出了前輩。

但是，你雖然可以把信紙換成薰衣草的顏色，你卻無(wú)論如何也無(wú)法發(fā)出有薰衣草香氣的信來(lái)。有時(shí)候，歪歪扭扭的手寫字，要比你選擇的任何字體都能代表你的心意?！阈菹肽秒娮余]件寫出完美的情書來(lái)。呵呵。

好了，言歸正傳，我們先列舉一下電子郵件的特性吧。

1、只讀：電子郵件的只讀特性與它的前輩一樣，你無(wú)法改掉別人發(fā)給你的郵件，你只能選擇保留還是扔掉它。因?yàn)檫@一點(diǎn)，電子郵件是有法律上的證據(jù)意義的。以我的了解，世界上某些國(guó)家——包括中國(guó)，都可以用電子郵件存根作為證據(jù)。
2、異步：異步的消息發(fā)送方式，使得非同時(shí)工作（時(shí)區(qū)差異、地區(qū)差異等）變得容易，而且使得個(gè)人工作的安排和調(diào)度方式更加靈活（你可以選擇何時(shí)去收郵件，收到郵件后何時(shí)進(jìn)行處理）。
3、高效：雖然，相對(duì)于前輩，電子郵件的發(fā)送和接收都容易了很多。但是，由于電子郵件仍然是郵件。在書寫電子郵件的時(shí)候，仍然需要經(jīng)過(guò)一定的構(gòu)思。務(wù)必達(dá)到條理清晰、言簡(jiǎn)意賅的程度。雖然不能實(shí)現(xiàn)實(shí)時(shí)的溝通，在很多的情況下反倒會(huì)比實(shí)時(shí)的溝通有更高的溝通效果。
4、安全：基本上，所有的電子郵件服務(wù)器都采用了傳輸層加密了吧？如果再加入個(gè)人的公、私鑰加密的話。應(yīng)該說(shuō)郵件信息的安全還是比較容易得到保證的。
5、檢索容易：當(dāng)然，這也和電子郵件的管理方式有關(guān)。不過(guò)，無(wú)論如何，電子郵件都比IM的聊天記錄容易檢索。比無(wú)法進(jìn)行記錄和檢索的語(yǔ)音聊天要高更多
6、溝通方便：靈活的使用電子郵件，可以非常方便的實(shí)現(xiàn)網(wǎng)絡(luò)異步會(huì)議室。實(shí)現(xiàn)非常好的溝通效果（比如Apache的Malling List或者Google Groups——不得不說(shuō)，Google Groups是基于電子郵件的非常優(yōu)雅的應(yīng)用之一）。另外，通過(guò)靈活的使用CC。也可以非常大的提高溝通的效率。;)
7、使用方便：電子郵件已經(jīng)逐步的移動(dòng)化，不管是iPhone還是藍(lán)莓，電子郵件都是非常重要的功能之一。在現(xiàn)在如果你愿意，你可以隨時(shí)訪問(wèn)你的郵箱，發(fā)送、查看和管理郵件

好啦，就寫到這里吧。先在這里總結(jié)一下。下一篇再討論我的電子郵件管理方式。

1、良好的電子郵件溝通是高效工作的重要組成部分。Apache就是靠這個(gè)成功的，相信它吧。
2、電子郵件的異步和檢索容易的特性，對(duì)電子郵件的管理提出了很高的要求，在這一點(diǎn)上，有好的電子郵件管理方式要比沒(méi)有工作效率高很多
3、你終究會(huì)發(fā)現(xiàn)可以在任何時(shí)間、任何地點(diǎn)、任何機(jī)器上管理你的郵件是多么重要的一件事情。所以，放棄POP3，擁抱IMAP吧。

posted @ 2008-08-22 20:38 guitarpoet 閱讀(481) | 評(píng)論 (0) | 編輯 收藏

關(guān)于個(gè)人文檔管理－圖片和視頻文件

昨天又寫了一篇又臭又長(zhǎng)的文章。從今天起，篇幅力圖達(dá)到短小精悍。

我不是一個(gè)攝影愛(ài)好者（所以到現(xiàn)在還沒(méi)有數(shù)碼相機(jī)），也不是一個(gè)很愛(ài)拍照的人。我自己拍得最多的就是每周一次用筆記本拍的減肥效果記錄。

由于電影一般看完就刪、很多音樂(lè)視頻都可以在網(wǎng)上看，而我又不愛(ài)看電視節(jié)目，所以我的視頻簡(jiǎn)直屈指可數(shù)。

視頻和圖片的最大的特點(diǎn)就是它們都是大把吃掉硬盤的怪物。舉例來(lái)說(shuō)，一個(gè)SRV的Live from Austin Texas就吃掉了我700M的硬盤。我的工作區(qū)中所有的文檔大小的總和都不及它的一半。

我對(duì)待視頻的策略，仍然是我用的最熟的大抽屜策略：最?？吹暮婉R上要看的視頻（比如最新的電影），放到Movies文件夾中。其他需要保留的經(jīng)典，刻盤保存（太大了，裝它們移動(dòng)硬盤吃不消）。

由于我再看它們的可能性不是非常的大，所以刻盤保存的風(fēng)險(xiǎn)我可以接受。

我使用iPhoto來(lái)管理我的圖片。用iPhoto來(lái)管理相片的體驗(yàn)，和用iTunes管理音樂(lè)差不多。只不過(guò)播放列表變成了相冊(cè)。我自定義了一個(gè)關(guān)鍵字“減肥日記“（開(kāi)始是想每天照，可是我實(shí)在太懶，呵呵），我每周拍的減肥效果記錄都會(huì)加上這個(gè)關(guān)鍵字。在這個(gè)基礎(chǔ)上，我建立了一個(gè)查詢，列出所有關(guān)鍵字為”減肥日記“的相片。這樣，我的減肥效果就可以一目了然了。哈哈。

總結(jié)一下：

1、視頻由于體積大，收看次數(shù)較少。可以考慮采用刻盤歸檔的方式。但是一定要預(yù)留一些空間使用大抽屜原則（常用的東西放到最容易找到的地方）。在使用刻盤保存的時(shí)候，一定要考慮為所有的光盤建立可供檢索和查詢的索引（光盤的編號(hào)、光盤的內(nèi)容、光盤的存檔時(shí)間）。對(duì)于個(gè)人而言，這些只要一個(gè)Excel表格足矣，不需要什么額外的軟件。
2、圖片的管理方案與音樂(lè)異曲同工。因?yàn)槌嗣浇楹褪褂梅绞接兴煌?。二者的根本都是大的二進(jìn)制文件 ＋ 圍繞這個(gè)文件的一系列元數(shù)據(jù)。而且，與音樂(lè)一樣圖片數(shù)據(jù)的備份和查看也被iPod很好的支持。

關(guān)于我的圖片和視頻的管理方式，就到這里吧。下一篇需要討論的，是對(duì)工作非常重要的，電子郵件的管理。由于它太重要了，而且涉及到的技巧也太多了（很多人都有很優(yōu)秀的經(jīng)驗(yàn)）。如果一篇寫不完，可以考慮多寫幾篇。:-)

posted @ 2008-08-19 09:32 guitarpoet 閱讀(1186) | 評(píng)論 (2) | 編輯 收藏

關(guān)于個(gè)人文檔管理 — 個(gè)人音樂(lè)管理

好了，接著昨天的話題，說(shuō)一下我的音樂(lè)文件管理。

托生在中國(guó)的福，我只花了很少的代價(jià)，就聽(tīng)到了很多高質(zhì)量的音樂(lè)（誰(shuí)都知道是怎么回事，呵呵）。

對(duì)于我這種須臾離不開(kāi)音樂(lè)的人來(lái)說(shuō)。找到自己今天、現(xiàn)在想聽(tīng)的音樂(lè)。并不是一件非常容易的事情。

說(shuō)起個(gè)人的音樂(lè)管理，我打算從革命的傳家史開(kāi)始。

我的音樂(lè)管理可以分為下面幾個(gè)階段。

1、卡帶 ＋ 錄音機(jī)：
    所有的卡帶都放到寫字臺(tái)的大抽屜里。大抽屜放不下后，則把所有的音樂(lè)分成兩批：常聽(tīng)的、不常聽(tīng)的。不常聽(tīng)的放到寫字臺(tái)的柜子里。常聽(tīng)的放到大抽屜里（對(duì)，就像當(dāng)時(shí)賣卡帶的店一樣，不過(guò)是按照個(gè)人好惡來(lái)排序的，最愛(ài)聽(tīng)的，放到最外面）。
   
    當(dāng)我要開(kāi)始聽(tīng)音樂(lè)的時(shí)候（也就是寫作業(yè)或者看書的時(shí)候），我會(huì)拿出五盤卡帶（要知道5 × 45，時(shí)間也不短了，呵呵）。作為最終手頭的音樂(lè)。

2、卡帶 ＋ 隨身聽(tīng)：
    我有了第一個(gè)隨身聽(tīng)的時(shí)候，終于可以實(shí)現(xiàn)邊走路邊聽(tīng)歌的欲望了。從那個(gè)時(shí)候起，我的書包里開(kāi)始放卡帶。不過(guò)，雖然設(shè)備升級(jí)了，我還是用以前的管理方式。

3、CD ＋ CD隨身聽(tīng)
    我在有CD隨身聽(tīng)之前就開(kāi)始聽(tīng)CD了（托VCD流行的福）。開(kāi)始我的CD不多，沒(méi)過(guò)多久就有PC了（大學(xué)的時(shí)候）。所以，這個(gè)階段乏善可陳。

4、PC ＋ 播放器 ＋ MP3（硬件設(shè)備，呵呵）
    有了CD、PC和MP3之后，卡帶對(duì)我就已經(jīng)成了歷史，我成功的以不算太低的價(jià)格（2元一盤？）把我所有的卡帶都甩了出去，除了幾個(gè)實(shí)在舍不得的（比如魯?shù)婪虻呢惗喾忆撉僮帏Q曲、布魯諾的馬勒第九）。當(dāng)時(shí)用的播放器是Windows Media Player、金山影霸（多難聽(tīng)的名字？）。文件管理也很簡(jiǎn)單，每個(gè)CD一個(gè)文件夾。而且，沒(méi)有任何的元數(shù)據(jù)，全是Track1.wma、Track9.wma，呵呵。

    我的第一個(gè)MP3小得可憐，128M。放我從CD抓的WMA文件，只能放一張專輯多（放交響曲的話，最多也就是兩個(gè)）。只能每天都在曲庫(kù)（一個(gè)文件夾——跟我管理的卡帶的大抽屜異曲同工）里挑——真的是精挑細(xì)選。

    之后是刪除、拷貝操作。然后是打開(kāi)MP3的循環(huán)播放。

    在PC上，我有幾個(gè)常用的播放列表。這樣在使用WMP的時(shí)候，就可以很容易找到自己想聽(tīng)的歌了。

    這種方式非常差勁，我經(jīng)常會(huì)丟掉我的元數(shù)據(jù)、播放列表，尤其是在重裝系統(tǒng)的時(shí)候。

5、PC ＋ iTunes ＋ iPod——現(xiàn)在
    經(jīng)過(guò)多年，我還是入了Apple的賊船，進(jìn)入了iPod的圈套。好了，我來(lái)仔細(xì)的講一下我現(xiàn)在的音樂(lè)管理吧。

我現(xiàn)在的音樂(lè)管理方式：

1、所有音樂(lè)集中管理：
    我盡可能的把我所有的音樂(lè)都集中的管理起來(lái)（目前是幾百?gòu)垖］嫲伞欢啵?，十幾個(gè)G的音樂(lè)統(tǒng)一的交給iTunes來(lái)管理。我之后買的所有的CD，全都是在用iTunes抓軌之后收藏。只聽(tīng)iTunes管理的音樂(lè)。

2、收集和整理音樂(lè)的元數(shù)據(jù)：
    對(duì)于音樂(lè)，iTunes可以支持的元數(shù)據(jù)有：名稱、表演者、年份、歌詞、專輯表演者、軌道編號(hào)、BPM、專輯名、專輯圖、光盤編號(hào)、風(fēng)格、作曲、歸類、注釋、評(píng)價(jià)、音量、均衡器、播放次數(shù)。
   
    其中后面的歸類、注釋、評(píng)價(jià)、音量、均衡器、播放次數(shù)這些元數(shù)據(jù)是可以自行定義的，而前面的元數(shù)據(jù)則是可以通過(guò)各種方式來(lái)獲取到的。

    我在抓取CD的時(shí)候，一定會(huì)保證iTunes能夠正常的連接到互聯(lián)網(wǎng)。讓它通過(guò)互聯(lián)網(wǎng)替我找到唱片的元數(shù)據(jù)。并把這些元數(shù)據(jù)保存在抓取的文件以及曲庫(kù)中。我也盡我最大的能力把其余欠缺的元數(shù)據(jù)補(bǔ)充上（從網(wǎng)上下載的音樂(lè)，一般說(shuō)來(lái)，元數(shù)據(jù)都損失得很大——有的下載站確實(shí)太過(guò)分了，把所有的元數(shù)據(jù)都刷成它們的網(wǎng)址）。

3、建立播放列表
    要想時(shí)刻找到想聽(tīng)的音樂(lè)，播放列表是必不可少的（尤其對(duì)iPod而言）。我機(jī)器上建立的播放列表，基本上都是以精選為主（比如On my way、On my way II等），因?yàn)槲以谧?、船、走路的時(shí)候，更多的是聽(tīng)podcast或者是聽(tīng)隨機(jī)播放。只有在某些嘈雜的場(chǎng)合（比如飛機(jī)上或者聽(tīng)podcast聽(tīng)累了）或者是不便于操作iPod的時(shí)候（比如騎自行車的時(shí)候）才會(huì)改聽(tīng)精選。我的精選是我精心的挑的高頻段比較明顯，并且旋律一般都處于高頻段的音樂(lè)，這樣可以盡量的避免周圍環(huán)境噪音對(duì)音樂(lè)的干擾，卻可以讓我能夠盡可能的聽(tīng)清周圍的聲音。

4、建立并保存查詢
    iTunes的查詢能力做得很不錯(cuò)，而且你可以把查詢作為動(dòng)態(tài)的播放列表保存。這個(gè)概念很讓人受用（尤其在音樂(lè)的元數(shù)據(jù)得到良好的維護(hù)之后）。我的智能播放列表不多，列舉幾個(gè)吧：Ragtime（我的所有風(fēng)格是Ragtime的音樂(lè)列表）、JS Bach By Gould（我的所有由Gould演奏的作曲家為JS Bach的音樂(lè)列表）、My Favorite not played since last week（所有我的評(píng)價(jià)在四星以上并且至少有一周沒(méi)有播放過(guò)的音樂(lè)列表）

5、隨機(jī)播放
    對(duì)于我來(lái)說(shuō)，我有數(shù)千個(gè)音樂(lè)文件（肯定會(huì)有人比我更多，比如我的一個(gè)朋友，光CD就數(shù)千），天天從中挑想聽(tīng)的音樂(lè)，是一件很乏味的事情，而且會(huì)造成過(guò)度的挑食。更有趣的是，有時(shí)候我都會(huì)忘記我有某個(gè)專輯。而有的專輯我抓進(jìn)我的曲庫(kù)之后，一次都沒(méi)有聽(tīng)過(guò)。而且，不同的時(shí)候、不同的情緒，聽(tīng)不同的音樂(lè)也有不同的感覺(jué)。

    所以我的策略是一般的情況下，我都是用隨機(jī)播放。如果這首歌不喜歡，就給個(gè)差評(píng)，跳到下一首。讓iTunes來(lái)幫我記錄播放次數(shù)。這個(gè)元數(shù)據(jù)對(duì)我管理音樂(lè)和評(píng)價(jià)音樂(lè)也有很高的應(yīng)用價(jià)值。而iPod能夠很好的支持這個(gè)元數(shù)據(jù)。僅為這一點(diǎn)，我就離不開(kāi)iTunes和iPod了。

6、下載和管理podcast
    聽(tīng)/看Podcast真是一件讓人上癮的事情。iTunes把Podcast區(qū)別對(duì)待的方式，是我最舒服的方式（因?yàn)槲揖褪怯昧薸Tunes后開(kāi)始聽(tīng)Podcast的，第一印象永遠(yuǎn)是最有力的）。

    我訂閱了二十幾個(gè)podcast，到現(xiàn)在只有二百多個(gè)文件，而且，podcast的最大特點(diǎn)就是時(shí)效性特別強(qiáng)，一般是聽(tīng)完、看完一遍就刪掉了，所以不存在管理的問(wèn)題。

7、其他格式的音樂(lè)
    iTunes支持播放的音樂(lè)格式很少。為了統(tǒng)一的管理所有的音樂(lè)，我把所有的其他格式的音樂(lè)都轉(zhuǎn)成了MP3。

8、iPod移動(dòng)方案
    我的由iTunes管理的音樂(lè)（Podcast ＋ 音樂(lè) ＋ iPod能播放的視頻）總共不到20G。裝在我的30G的iPod中綽綽有余。我每次出門都會(huì)帶著我所有的音樂(lè)。我在使用iPod之前絕對(duì)會(huì)認(rèn)為這是不可思議的。

9、備份管理
    我的所有音樂(lè)都在我的MacBook里。MacBook是源。我的30G iPod與MacBook完全同步，是第一手備份。我還有一個(gè)120G的專有備份移動(dòng)硬盤（用來(lái)備份我的Home文件夾，當(dāng)然，同時(shí)也就備份了音樂(lè)、和iTunes元數(shù)據(jù)——以后會(huì)說(shuō)）是第二手備份。我覺(jué)得我有足夠的信心相信這三個(gè)設(shè)備不會(huì)同時(shí)壞掉，只要有一個(gè)備份，我就能恢復(fù)我所有的音樂(lè)。我不刻盤，盤刻多了不好管理。而且，光盤更不好保存，不如硬盤——起碼我覺(jué)得，當(dāng)然了，我買不起磁帶機(jī)。

回顧到現(xiàn)在，我覺(jué)得這么多年來(lái)，我仿佛在音樂(lè)管理方面沒(méi)有任何進(jìn)步，進(jìn)步的只是技術(shù)。呵呵。

總結(jié)一下：

1、我認(rèn)為，個(gè)人的音樂(lè)應(yīng)該統(tǒng)一的交給一個(gè)軟件來(lái)統(tǒng)一的進(jìn)行管理 —— 原因，使用和備份都方便。能夠?qū)崿F(xiàn)一套元數(shù)據(jù)是最好的
2、音樂(lè)應(yīng)該是隨機(jī)的聽(tīng)的
3、音樂(lè)的元數(shù)據(jù)非常重要，尤其是在你對(duì)音樂(lè)要求很高或者你的音樂(lè)非常多的時(shí)候
4、要善用音樂(lè)管理軟件的自定義查詢功能，能夠發(fā)揮個(gè)人的創(chuàng)意就更好了

當(dāng)然，現(xiàn)在網(wǎng)絡(luò)的音樂(lè)電臺(tái)也是聽(tīng)音樂(lè)的一個(gè)非常不錯(cuò)的選擇。不過(guò)極其可惜的是Pandora并不面向大陸開(kāi)放。而感覺(jué)大陸的網(wǎng)絡(luò)音樂(lè)電臺(tái)中我想聽(tīng)的音樂(lè)并不是很多。

我很看好網(wǎng)絡(luò)音樂(lè)電臺(tái)。試想，如果能夠?qū)崿F(xiàn)網(wǎng)絡(luò) ＋ PC ＋ 手機(jī)的無(wú)縫結(jié)合。保證可以隨時(shí)聽(tīng)到想聽(tīng)的高質(zhì)量的音樂(lè)，并且系統(tǒng)可以統(tǒng)一的管理所有你相關(guān)的音樂(lè)的元數(shù)據(jù)。又可以免去管理、維護(hù)音樂(lè)文件的煩惱。是多么愜意的事情？

我愿意為這個(gè)服務(wù)付費(fèi)，因?yàn)槲颐刻於家?tīng)音樂(lè)，所以即使是每天10元（也就是每年4K的服務(wù)費(fèi)，我也可以接受——因?yàn)槲疫€省去了購(gòu)買專輯和維護(hù)CD的支出）。

posted @ 2008-08-18 12:49 guitarpoet 閱讀(716) | 評(píng)論 (0) | 編輯 收藏

關(guān)于個(gè)人文檔管理

 這幾天開(kāi)始整理個(gè)人文檔。整理的過(guò)程中，感覺(jué)到有必要把我在個(gè)人文檔管理中的一些經(jīng)驗(yàn)總結(jié)一下。

誠(chéng)然，一個(gè)人的文檔管理風(fēng)格，跟一個(gè)人的性格和能力有很大的關(guān)系，跟他的臥室（如果是結(jié)婚了的話，那就看辦公室吧）也有很大的關(guān)系。:-)

其實(shí)，優(yōu)秀的個(gè)人文檔管理的精髓就是能夠在需要的時(shí)候找到需要的東西（當(dāng)然，是自己的東西）。不管你用何種方式，不管你采用何種手段。

首先，我打算區(qū)分一下個(gè)人電子文檔的類別。

所有的個(gè)人電子文檔都可以就需不需要進(jìn)行變更管理分成兩類：需要進(jìn)行變更管理的和不需要進(jìn)行變更管理的。

不需要進(jìn)行變更管理的最典型例子就是郵件。一旦閱讀完畢，它就變成了歷史，只有查閱和轉(zhuǎn)發(fā)的功能了。各種電子書、電子文檔、媒體文件（音樂(lè)、視頻、圖片等）等，它們和電子郵件的情形基本一樣，對(duì)一般人來(lái)說(shuō)也都是不需要進(jìn)行變更管理的。

需要進(jìn)行變更管理的文檔，我把它們一律稱之為工作文檔。關(guān)于工作文檔的管理，我打算在討論完不需要進(jìn)行變更管理的文檔以后再討論。

那么，不需要進(jìn)行變更管理的文檔。怎樣進(jìn)行管理比較好呢？

我先說(shuō)說(shuō)我自己的經(jīng)驗(yàn)吧。

我把我的不需要進(jìn)行變更管理的文檔分成5種類型：音樂(lè)、視頻、圖片、Email和電子書。

我打算在下一篇的blog里，寫寫我的音樂(lè)文件的管理方式。

posted @ 2008-08-17 09:10 guitarpoet 閱讀(1573) | 評(píng)論 (2) | 編輯 收藏

關(guān)于基于JavaSript的RIA客戶端數(shù)據(jù)處理（下）

一、引子

上一篇討論了關(guān)于客戶端數(shù)據(jù)處理的一些問(wèn)題，以簡(jiǎn)單的用例場(chǎng)景的方式描述了出來(lái)。很明顯，要想實(shí)現(xiàn)一個(gè)功能完整的Rich客戶端的話，必須能夠滿足上述用例場(chǎng)景的需求。能否根據(jù)這些需求做出合理的設(shè)計(jì)，是一個(gè)挑戰(zhàn)。尤其對(duì)于設(shè)計(jì)而言，不同的人有著不同的風(fēng)格，而且由于背景不同，也會(huì)有不同的見(jiàn)解。本文中，我只是陳述出自己的一些想法和設(shè)想，更多的是希望能夠拋磚引玉，通過(guò)在這個(gè)方面的討論也能增進(jìn)我的理解。呵呵。

很顯然，blog的形式更適合作為思路的介紹以及探討的平臺(tái)，而不是詳細(xì)設(shè)計(jì)的文檔。而且很明顯這一篇文章是承載不了所有的詳細(xì)設(shè)計(jì)的。我爭(zhēng)取把我在各個(gè)細(xì)化的方面的想法在后續(xù)的文章里面發(fā)出來(lái)。如果時(shí)間允許的話，整理出初始的文檔和代碼，建立一個(gè)小的開(kāi)源項(xiàng)目未嘗不可（因?yàn)槿绱耍械腏S都是采用英文來(lái)注釋──其實(shí)還有一個(gè)原因是練習(xí)英文 :)）。這都是后話了。

二、縮略語(yǔ)

1. RIA：Rich Internet Application的縮寫。RIA是擁有傳統(tǒng)本地應(yīng)用的功能和效果的Web應(yīng)用。RIA一般把UI相關(guān)的處理交給了Web客戶端，但是大量的數(shù)據(jù)（包括應(yīng)用的狀態(tài)、數(shù)據(jù)等）還是交給服務(wù)端處理

2. Ajax：又寫為AJAX，是"Asynchronous JavaScript and XML"的縮寫。是一種使用瀏覽器技術(shù)進(jìn)行RIA開(kāi)發(fā)的技術(shù)

3. Prototype：開(kāi)源的優(yōu)雅的Ajax以及JavaScript基礎(chǔ)擴(kuò)展框架。由于被Rails采用而聞名，使用相當(dāng)廣泛
4. jQuery：功能類似Prototype + script.aculo.us的開(kāi)源Ajax框架。據(jù)我所知，Google用得比較多
   
5. Ext：對(duì)YUI的一個(gè)擴(kuò)展的UI構(gòu)件庫(kù)。經(jīng)過(guò)改進(jìn)后，可以使用jQuery或者Prototype作為基礎(chǔ)。目前好像正在完善自身的基礎(chǔ)Ext base。以優(yōu)秀的構(gòu)件聞名。雖然目前仍然屬于商業(yè)構(gòu)件庫(kù)，但是License相對(duì)寬松，一般的商業(yè)應(yīng)用可以免費(fèi)使用
   

6. dojo：由dojo foundation管理的一個(gè)開(kāi)源JavaScript框架。提供了很好的JavaScript擴(kuò)展，目前被IBM和Sun等大公司支持和使用

7. Json： JavaScript Object Notation的縮寫。它是一種純文本的數(shù)據(jù)對(duì)象傳輸協(xié)議，在Ajax的應(yīng)用中被廣泛采用

8. CRUD：Create（創(chuàng)建）、Retrieve（獲?。?/span>Update（更新）和Delete（刪除）這四種簡(jiǎn)單的數(shù)據(jù)操作的縮寫

9. Form：本文中的Form指的是經(jīng)過(guò)Ajax擴(kuò)展的簡(jiǎn)單的HTML電子表單。表單內(nèi)部可以擁有很多如ComboBox、TextBox等構(gòu)件。一般來(lái)說(shuō)，一個(gè)表單對(duì)應(yīng)著一個(gè)業(yè)務(wù)的數(shù)據(jù)對(duì)象

10. Tree：樹(shù)形顯示結(jié)構(gòu)化數(shù)據(jù)的構(gòu)件，由于數(shù)據(jù)是高度結(jié)構(gòu)化的，往往可以采用懶加載等技術(shù)來(lái)提高性能

11. Grid：以表格形式顯示和編輯數(shù)據(jù)的UI構(gòu)件。一般分為表頭（標(biāo)題欄）、表身（數(shù)據(jù)列表）和表尾（合計(jì)、狀態(tài)顯示等）三個(gè)部分。其中，表頭可以是復(fù)合的表頭，而表身可以是復(fù)合的格式（Tree、Grid、ComboBox、CheckBox等）。一個(gè)Grid可以有一個(gè)復(fù)雜的Grid定義

12. Enhanced Grid：下面簡(jiǎn)稱為EGrid，是Grid的擴(kuò)展。在Grid的功能基礎(chǔ)之上提供了數(shù)據(jù)獲取和數(shù)據(jù)持久化的能力，可以大大的減少開(kāi)發(fā)應(yīng)用的時(shí)間（Ext中的Grid可以認(rèn)為是一個(gè)簡(jiǎn)化了的EGrid）

13. CodeList：代碼表，一般用在下拉列表數(shù)據(jù)處，在系統(tǒng)的實(shí)現(xiàn)中，由于性能以及標(biāo)準(zhǔn)的要求，下拉列表一般都是采用代碼保存數(shù)據(jù)，但是用戶在填寫表單的時(shí)候需要看到正常的文字而不是代碼，這就需要系統(tǒng)通過(guò)CodeList進(jìn)行文字和代碼的轉(zhuǎn)換

14. LRU：Least Recent Used的縮寫，是一種簡(jiǎn)單的緩存策略，如果緩存已滿，那么就釋放最近最少使用的那個(gè)緩存數(shù)據(jù)

15. REST：是REpresentational State Transfer的縮寫，是一種基于輕量級(jí)WebService協(xié)議

16. JDBC：是Java DataBase Connectivity對(duì)縮寫，是基于Java的數(shù)據(jù)庫(kù)連接規(guī)范。

三、基礎(chǔ)

既然決定采用Ajax，就最好采用一個(gè)基礎(chǔ)，在這個(gè)有很多優(yōu)秀的Ajax框架可供選擇的時(shí)代，誰(shuí)要是還要赤手空拳的來(lái)寫Ajax應(yīng)用，就未免有點(diǎn)兒過(guò)于勇敢，而近于魯莽了。這篇文章不是Ajax框架對(duì)比文章，我不打算在這里一一列舉各個(gè)流行的Ajax框架的優(yōu)缺點(diǎn)，我只拿下面幾個(gè)進(jìn)行討論，dojo、Prototype、jQuery、Ext。

先提需求，框架應(yīng)該：

1. 以一種形式支持面向?qū)ο螅ó吘归_(kāi)發(fā)人員多數(shù)都是Java程序員，更有可能的是，他/她只對(duì)Java熟悉）
2. 以一種方式來(lái)支持命名空間和分包機(jī)制（開(kāi)發(fā)企業(yè)應(yīng)用與開(kāi)發(fā)網(wǎng)站不同，復(fù)雜的不是技術(shù)而是業(yè)務(wù)。沒(méi)有命名空間和分包支持，對(duì)于大型應(yīng)用，基本不可控制。──設(shè)想一下如果Java沒(méi)有package關(guān)鍵字會(huì)怎樣）
3. 有完善的模塊封裝與管理規(guī)范或者最佳實(shí)踐，能夠自動(dòng)處理模塊間的依賴則更好（模塊的定義不在這里解釋了，一個(gè)例子說(shuō)明吧，一個(gè)Jar就是一個(gè)模塊。模塊化和構(gòu)件化是實(shí)現(xiàn)、維護(hù)和管理大型應(yīng)用的重要手段）
4. 提供豐富的調(diào)優(yōu)選項(xiàng)，使得對(duì)復(fù)雜的應(yīng)用調(diào)優(yōu)是可能的（這一點(diǎn)對(duì)于UI層尤為重要，因?yàn)樗苯用鎸?duì)使用者）
5. 便于調(diào)試（這一點(diǎn)對(duì)于開(kāi)發(fā)者致關(guān)重要）

綜合上面幾點(diǎn)，我選擇dojo作為基礎(chǔ)。Sorry Prototype。

四、整體構(gòu)架

整體構(gòu)架如下圖所示（為了便于理解UI構(gòu)件與其對(duì)關(guān)系，我把需要數(shù)據(jù)處理的UI構(gòu)件也加了上去，圖中藍(lán)背景色的部分就是）：
一目了然，整個(gè)客戶端數(shù)據(jù)處理由3個(gè)部分構(gòu)成，DataSource、DataSet和DataStore。下面分別進(jìn)行簡(jiǎn)單的介紹。

五、DataSet

DataSet的概念很簡(jiǎn)單，就是數(shù)據(jù)對(duì)象的集合。它的構(gòu)架如下圖所示（注意：DataSet只是一套標(biāo)準(zhǔn)的API，可以有不同的實(shí)現(xiàn)——比如XML形式的）：

如圖所示，DataSet由四個(gè)部分構(gòu)成，Record Set（數(shù)據(jù)集合）、Change Tracker（數(shù)據(jù)變更追蹤）、Meta Data（數(shù)據(jù)對(duì)象源信息）和Cursors（游標(biāo)API）。

分別介紹如下：

1. Record Set：Record Set就是Record的集合，一個(gè)Record就是一個(gè)數(shù)據(jù)對(duì)象，它由一系列的屬性（Property）構(gòu)成，屬性是一個(gè)簡(jiǎn)單的字符串，其對(duì)應(yīng)的值可以是任意類型。Record提供屬性讀寫的方法，可以直接在Record上對(duì)屬性進(jìn)行讀寫，并且，Record會(huì)為寫操作提供一個(gè)事件。Record Set內(nèi)部的元素必須是Record，Record Set支持對(duì)內(nèi)部Record的CRUD操作。并且會(huì)有相應(yīng)的事件觸發(fā)
2. Change Tracker：ChangeTracker為DataSet提供所有寫操作的追蹤，可以通過(guò)配置選擇Change Tracker是否記錄修改，如果記錄修改，采用的是針對(duì)每一個(gè)Record記錄增加、刪除以及針對(duì)每一個(gè)屬性記錄First和Last修改的策略
3. Meta Data：提供DataSet中Record的元數(shù)據(jù)（屬性名、屬性對(duì)應(yīng)類型、其他自定義數(shù)據(jù)——校驗(yàn)、Form Label信息、表頭信息等）以及DataSet的元數(shù)據(jù)（在全部數(shù)據(jù)中的位置等）。
4. Cursors：Cursor其實(shí)就是Record的迭代器，可以通過(guò)對(duì)dataset查詢（一般都是非常簡(jiǎn)單的filter或者range）得到，推薦通過(guò)Cursor進(jìn)行Record訪問(wèn)，而不是通過(guò)Index，因?yàn)橥ㄟ^(guò)迭代器訪問(wèn)Record，DataSet擁有更多的能力。雖然通過(guò)Cursor完全可以訪問(wèn)所有的Record及其中的數(shù)據(jù)，但是由于DataSet擁有MetaData，所以還是采用DataSet作為數(shù)據(jù)綁定的主體

DataSet是整個(gè)客戶端數(shù)據(jù)處理構(gòu)架的核心，所有的數(shù)據(jù)訪問(wèn)都應(yīng)該通過(guò)DataSet的API。這樣客戶端的數(shù)據(jù)處理才是統(tǒng)一的一個(gè)整體。

解決的用例問(wèn)題：

• 數(shù)據(jù)綁定：Form綁定、Grid綁定
• 數(shù)據(jù)變更追蹤：Grid變更提示、數(shù)據(jù)集合變更追蹤、Form修改的追蹤
• 數(shù)據(jù)訪問(wèn)：數(shù)據(jù)對(duì)象元數(shù)據(jù)信息訪問(wèn)、數(shù)據(jù)寫操作的統(tǒng)一事件定義、統(tǒng)一的數(shù)據(jù)讀取方式

六、DataSource

DataSource的功能是提供對(duì)數(shù)據(jù)進(jìn)行查詢以及數(shù)據(jù)的持久化（持久化到客戶端或者服務(wù)器端）。與DataSet一樣，不同的格式數(shù)據(jù)就會(huì)有不同的DataSource，一種DataSource代表了一種客戶端與服務(wù)端的數(shù)據(jù)傳輸協(xié)議。但是由于DataSource的邏輯與結(jié)構(gòu)過(guò)于復(fù)雜（事實(shí)上，DataSet的實(shí)現(xiàn)也完全依賴DataSource的實(shí)現(xiàn)，可以類比JDBC），不應(yīng)該對(duì)每一種格式都重新實(shí)現(xiàn)一個(gè)DataSource，由此，DataSource不應(yīng)該是一套標(biāo)準(zhǔn)的API，而是使用了Adapter模式，來(lái)滿足不同的數(shù)據(jù)來(lái)源，其構(gòu)架如下圖所示：
看上去很簡(jiǎn)單？實(shí)際上這是最復(fù)雜的部分，關(guān)于這個(gè)部分，至少可以再寫3篇文章來(lái)詳細(xì)探討，在本文中，就不過(guò)度討論了。:)

如圖所示，DataSource由Cache、Query、Persist以及Providers構(gòu)成，分別介紹如下：

1. Cache：Cache的概念在前面已經(jīng)闡述了，不在這里多說(shuō)了。在這里簡(jiǎn)單的介紹一下客戶端Cache的策略以及技術(shù)，由于基于瀏覽器的數(shù)據(jù)緩存技術(shù)非常重要，擬在后續(xù)的文檔《客戶端的緩存策略與相關(guān)技術(shù)》中對(duì)其進(jìn)行詳細(xì)討論
• 緩存策略（這一方面客戶端數(shù)據(jù)的緩存與服務(wù)端的數(shù)據(jù)緩存考慮的問(wèn)題應(yīng)該是類似的，唯一的區(qū)別是，客戶端的數(shù)據(jù)緩存不必考慮集群支持。:)）
• LRU：基礎(chǔ)的Cache算法，如果緩存已滿時(shí)，根據(jù)最近很少使用算法來(lái)確定哪些對(duì)象需要被清除
• Priority：按照優(yōu)先級(jí)高低來(lái)清理緩存空間的策略，當(dāng)緩存已滿時(shí)，按照優(yōu)先級(jí)高低來(lái)確定哪些對(duì)象需要被清除，可以與LRU算法共存
• Refreshable：有時(shí)效性的數(shù)據(jù)，或者在運(yùn)行時(shí)有可能會(huì)被修改需要同步或者刷新的數(shù)據(jù)?？梢栽O(shè)置數(shù)據(jù)過(guò)期時(shí)間，到時(shí)間則數(shù)據(jù)處于stale狀態(tài)，再度訪問(wèn)該數(shù)據(jù)時(shí)，如果不能重新獲得該數(shù)據(jù)，則報(bào)錯(cuò)
• Expireable：臨時(shí)性數(shù)據(jù)，可以設(shè)置失效時(shí)間，到時(shí)間則數(shù)據(jù)失效，在緩存需要清理時(shí)，緩存會(huì)清理掉這些失效的對(duì)象
• 緩存持久化（屬于高級(jí)的緩存策略，依賴客戶端基于JavaScript的數(shù)據(jù)存儲(chǔ)技術(shù)）
• Save（持久化）：把緩存當(dāng)中的數(shù)據(jù)持久化到本地或者服務(wù)端，其用處如下
• 通過(guò)把數(shù)據(jù)持久化可以增加Cache的容量
• 數(shù)據(jù)本地緩存提供了離線表單填寫的能力
• Retrieve、Delete：對(duì)緩存中數(shù)據(jù)的基本操作
• Sync：離線緩存的本地?cái)?shù)據(jù)，可以與遠(yuǎn)程服務(wù)端進(jìn)行同步，從而實(shí)現(xiàn)離線表單提交以及實(shí)現(xiàn)離線CodeList等功能
• 緩存技術(shù)
• Client
• 內(nèi)存引用
• Cookie
  
• Google Gear
• Server（服務(wù)端協(xié)助客戶端做一些緩存，這在傳統(tǒng)的B/S下是匪夷所思的設(shè)計(jì)，在RIA的情況下卻未嘗不是一種手段）
• WebService或者REST
• Post + Get
2. Query：其實(shí)Query只是一個(gè)方法，由于有可能會(huì)向服務(wù)端發(fā)XmlHttpRequest，所以這個(gè)方法需要回調(diào)方法。其參數(shù)應(yīng)該是一個(gè)Query對(duì)象，一個(gè)配置對(duì)象，有一些事件的關(guān)鍵字（onBegin、onError、onSuccess等）。Query對(duì)象以及配置對(duì)象的格式在本文中就不詳細(xì)說(shuō)明了，留給以后慢慢說(shuō)（因?yàn)檫@個(gè)部分是我最喜歡的部分）。很明顯，如果查詢成功，查詢的結(jié)果應(yīng)該是DataSet，一般來(lái)說(shuō)，DataSource是DataSet來(lái)源。不同的DataSource，查詢的語(yǔ)言未必相同。不一定所有的查詢對(duì)象都支持SQL語(yǔ)法（比如可以支持HQL或者XQuery啊），而且我最推薦采用的是服務(wù)端提供一個(gè)服務(wù)抽象層，接受Json格式的查詢請(qǐng)求，并返回Json格式的數(shù)據(jù)
3. Persist：數(shù)據(jù)持久化。只是Save和Update兩個(gè)方法。接受DataSet和配置對(duì)象作為參數(shù)（這兩個(gè)方法也應(yīng)該是異步的）。如果DataSet里面沒(méi)有足夠的元數(shù)據(jù)信息，需要在配置對(duì)象里面提供這些信息。這個(gè)部分不比Query部分復(fù)雜
4. Providers：數(shù)據(jù)的來(lái)源，提供了Query和Persist API的實(shí)現(xiàn)，是DataSource的底層實(shí)現(xiàn)，它使DataSource的實(shí)現(xiàn)可以跨不同協(xié)議而使用。給DataSource提供不同的Provider，DataSource就可以支持不同的數(shù)據(jù)傳輸協(xié)議。

DataSource是數(shù)據(jù)查詢和持久化的核心，所有的客戶端的數(shù)據(jù)查詢和持久化基本都應(yīng)該采用DataSource，從而獲得DataSource提供的強(qiáng)大而靈活的特性。

解決的用例問(wèn)題：

• 數(shù)據(jù)緩存：離線運(yùn)行的CodeList、離線表單填寫、性能考慮
• 數(shù)據(jù)查詢：樣本查詢、模糊查詢、Range查詢、邏輯查詢、自定義查詢
• 數(shù)據(jù)處理：數(shù)據(jù)處理事件、過(guò)濾、排序

七、DataStore

DataStore基于DataSource和DataSet的實(shí)現(xiàn)，實(shí)現(xiàn)了dojo的data api。這樣既實(shí)現(xiàn)了對(duì)需要dojo api的dojo構(gòu)件的支持，又滿足了類似Tree、EGrid這種既需要綁定又需要數(shù)據(jù)來(lái)源的高級(jí)構(gòu)件的要求?？傮w來(lái)說(shuō)，DataStore只是薄薄的一層接口，實(shí)際的實(shí)現(xiàn)完全依賴于DataSource。

解決的用例問(wèn)題：

• 數(shù)據(jù)綁定、查詢、處理：Tree綁定、ComboBox數(shù)據(jù)源、EGrid綁定

八、待討論的問(wèn)題

客戶端的數(shù)據(jù)處理事實(shí)上要比我想象得還要復(fù)雜，我還有一些設(shè)計(jì)決策沒(méi)有確定，列舉下來(lái)以供討論吧。

8.1 客戶端的事務(wù)處理？

由于很多數(shù)據(jù)處理都放在了客戶端?？蛻舳说臄?shù)據(jù)處理操作相應(yīng)增多而且復(fù)雜，是否應(yīng)該在DataSource中添加寫事務(wù)的處理？以便對(duì)數(shù)據(jù)操作進(jìn)行更細(xì)粒度的管理，而不是僅僅停留在Query、Save和Track階段？

8.2 權(quán)限數(shù)據(jù)的來(lái)源

如果可以連接到服務(wù)端，用戶在向服務(wù)端登錄后，服務(wù)端會(huì)返回用戶的權(quán)限信息列表?？蛻舳私邮蘸?，可以相應(yīng)的提供權(quán)限控制。但是，如果客戶端離線運(yùn)行，用戶無(wú)法向服務(wù)的登錄，權(quán)限信息列表無(wú)從獲得，怎么提供權(quán)限控制？

探討方案1：離線客戶端無(wú)須登錄，由于沒(méi)有權(quán)限控制列表，默認(rèn)擁有系統(tǒng)最低權(quán)限（固定的配置在客戶端），由系統(tǒng)開(kāi)發(fā)人員決定用戶在離線時(shí)可以進(jìn)行何種操作。用戶在線提交數(shù)據(jù)的時(shí)候，服務(wù)端也要根據(jù)相應(yīng)的權(quán)限進(jìn)行驗(yàn)證以防止越權(quán)的數(shù)據(jù)操作

探討方案2：離線客戶端仍須登錄，權(quán)限控制列表使用用戶在線登錄時(shí)緩存的數(shù)據(jù)。其余與在線方式相同。如果用戶沒(méi)有在線登錄過(guò)，那么離線應(yīng)用無(wú)法使用。

8.3 跨域數(shù)據(jù)的來(lái)源

由于瀏覽器的安全性策略，JavaScript無(wú)法向除本身域之外的其他服務(wù)器發(fā)送請(qǐng)求。也就是說(shuō)，對(duì)于JavaScript而言，所有的數(shù)據(jù)必須來(lái)源于同一個(gè)域的服務(wù)器。對(duì)客戶端進(jìn)行集成非常不利。

探討方案1：服務(wù)端提供一個(gè)服務(wù)接入層，接受如Spring Bean、EJB、JMS、WebService等形式的服務(wù)，并且把所有的服務(wù)都轉(zhuǎn)化成為一種固定格式的協(xié)議與客戶端交互。所有的服務(wù)集成與協(xié)議轉(zhuǎn)化都交給服務(wù)端，對(duì)客戶端完全透明。

探討方案2：服務(wù)端提供一個(gè)簡(jiǎn)單的Proxy，通過(guò)一定的協(xié)議把請(qǐng)求和回復(fù)轉(zhuǎn)發(fā)給客戶端，處理交給客戶端來(lái)做

九、小結(jié)

雖然到了這里，但是對(duì)于基于JavaScript的RIA客戶端數(shù)據(jù)處理的討論卻才剛剛開(kāi)始，還需要很多后續(xù)的展開(kāi)討論。但是，上午已經(jīng)過(guò)去了，需要去吃午飯了。:)

posted @ 2007-12-15 13:15 guitarpoet 閱讀(1449) | 評(píng)論 (2) | 編輯 收藏

關(guān)于基于JavaSript的RIA客戶端數(shù)據(jù)處理（上）

一、引子

這個(gè)blog已經(jīng)荒廢將近一年了，久也不寫，自然有很多的理由，但更多的怕是懶吧。不說(shuō)閑話了，轉(zhuǎn)入正題。

關(guān)于基于JavaScript的RIA客戶端數(shù)據(jù)處理這個(gè)話題，我打算分成兩篇文章來(lái)寫，一篇陳述我所總結(jié)出的基于B/S結(jié)構(gòu)的RIA客戶端數(shù)據(jù)處理的問(wèn)題，另一篇?jiǎng)t陳述針對(duì)這些問(wèn)題我所提出的技術(shù)解決方案構(gòu)架。

二、RIA？RIA！

關(guān)于RIA尤其是基于Ajax的RIA怕是屢見(jiàn)不鮮了吧？尤其是在Google推手之后，文字處理、表格處理、幻燈片放映這種看起來(lái)非常客戶端的應(yīng)用，都可以采用Ajax的技術(shù)來(lái)實(shí)現(xiàn)了。作為一個(gè)關(guān)注企業(yè)級(jí)應(yīng)用開(kāi)發(fā)的技術(shù)人員，一個(gè)很自然的想法就會(huì)產(chǎn)生，是否可以采用這種技術(shù)來(lái)改進(jìn)我們基于Java EE技術(shù)開(kāi)發(fā)的B/S結(jié)構(gòu)的企業(yè)應(yīng)用呢？

先說(shuō)有沒(méi)有必要，答案是肯定的。B/S被廣為詬病的一個(gè)問(wèn)題就是降低了最終用戶的操作效率，以我的經(jīng)驗(yàn)來(lái)說(shuō)，用戶雖然普遍的感到基于瀏覽器的界面要漂亮得多，用鼠標(biāo)操作也很直觀，但是卻實(shí)在比以前的界面復(fù)雜而且操作困難。而且每次頁(yè)面提交后的等待也實(shí)在是對(duì)工作效率的一個(gè)降低。當(dāng)然，我這里也沒(méi)有必要意義列舉B/S在客戶端的缺點(diǎn)，實(shí)際上這個(gè)問(wèn)題是被廣泛認(rèn)同的。

再說(shuō)可行性，可行性分為兩種：技術(shù)上的可行性以及工程開(kāi)發(fā)上的可行性。

技術(shù)上的可行性就無(wú)須驗(yàn)證了，Google Reader、Gmail、Google Docs的穩(wěn)定運(yùn)行都是非常好的證明。

但是它是否一定適合時(shí)間要求相對(duì)比較嚴(yán)格的工程開(kāi)發(fā)呢？

這就需要一個(gè)非常穩(wěn)定的平臺(tái)來(lái)進(jìn)行支持，而且由于工程開(kāi)發(fā)的特殊性，最好還要有可視化的開(kāi)發(fā)和調(diào)試環(huán)境才更有說(shuō)服力。目前看來(lái)是沒(méi)有非常完善的，但是很多的Ajax框架，如Ext、GWT、Tibco GI以及服務(wù)端框架Struts2、JSF等，都在以自己的方式實(shí)現(xiàn)著。關(guān)于這個(gè)方面的探討我打算放到下一個(gè)系列《基于MDA的企業(yè)應(yīng)用RIA解決方案》里面討論，不在這里多費(fèi)口舌了。

技術(shù)上是可行的，而如果又一個(gè)非常穩(wěn)定和成熟的平臺(tái)支持的話，在工程開(kāi)發(fā)上也是可行的，那么這個(gè)平臺(tái)怎樣才算是穩(wěn)定和成熟的呢？本系列討論的就是其中的一部分，客戶端的數(shù)據(jù)處理。

三、定義、縮略語(yǔ)

下面是本文中使用的技術(shù)名詞的定義以及縮略語(yǔ)簡(jiǎn)介。

1. RIA：Rich Internet Application的縮寫。RIA是擁有傳統(tǒng)本地應(yīng)用的功能和效果的Web應(yīng)用。RIA一般把UI相關(guān)的處理交給了Web客戶端，但是大量的數(shù)據(jù)（包括應(yīng)用的狀態(tài)、數(shù)據(jù)等）還是交給服務(wù)端處理

2. Ajax：又寫為AJAX，是"Asynchronous JavaScript and XML"的縮寫。是一種使用瀏覽器技術(shù)進(jìn)行RIA開(kāi)發(fā)的技術(shù)

3. ECMA Script：由European Computer Manufacturers Association（歐洲計(jì)算機(jī)制造商協(xié)會(huì)）維護(hù)的一個(gè)腳本語(yǔ)言標(biāo)準(zhǔn)。當(dāng)前最通行的版本是ECMA-262 Edition 3，通常也被稱為JavaScript 1.5

4. dojo：由dojo foundation管理的一個(gè)開(kāi)源JavaScript框架。提供了很好的JavaScript擴(kuò)展，目前被IBM和Sun等大公司支持和使用

5. Json： JavaScript Object Notation的縮寫。它是一種純文本的數(shù)據(jù)對(duì)象傳輸協(xié)議，在Ajax的應(yīng)用中被廣泛采用

6. CRUD：Create（創(chuàng)建）、Retrieve（獲?。?、Update（更新）和Delete（刪除）這四種簡(jiǎn)單的數(shù)據(jù)操作的縮寫

7. Form：本文中的Form指的是經(jīng)過(guò)Ajax擴(kuò)展的簡(jiǎn)單的HTML電子表單。表單內(nèi)部可以擁有很多如ComboBox、TextBox等構(gòu)件。一般來(lái)說(shuō)，一個(gè)表單對(duì)應(yīng)著一個(gè)業(yè)務(wù)的數(shù)據(jù)對(duì)象

8. Tree：樹(shù)形顯示結(jié)構(gòu)化數(shù)據(jù)的構(gòu)件，由于數(shù)據(jù)是高度結(jié)構(gòu)化的，往往可以采用懶加載等技術(shù)來(lái)提高性能

9. Grid：以表格形式顯示和編輯數(shù)據(jù)的UI構(gòu)件。一般分為表頭（標(biāo)題欄）、表身（數(shù)據(jù)列表）和表尾（合計(jì)、狀態(tài)顯示等）三個(gè)部分。其中，表頭可以是復(fù)合的表頭，而表身可以是復(fù)合的格式（Tree、Grid、ComboBox、CheckBox等）。一個(gè)Grid可以有一個(gè)復(fù)雜的Grid定義

10. Enhanced Grid：下面簡(jiǎn)稱為EGrid，是Grid的擴(kuò)展。在Grid的功能基礎(chǔ)之上提供了數(shù)據(jù)獲取和數(shù)據(jù)持久化的能力，可以大大的減少開(kāi)發(fā)應(yīng)用的時(shí)間（Ext中的Grid可以認(rèn)為是一個(gè)簡(jiǎn)化了的EGrid）

11. CodeList：代碼表，一般用在下拉列表數(shù)據(jù)處，在系統(tǒng)的實(shí)現(xiàn)中，由于性能以及標(biāo)準(zhǔn)的要求，下拉列表一般都是采用代碼保存數(shù)據(jù)，但是用戶在填寫表單的時(shí)候需要看到正常的文字而不是代碼，這就需要系統(tǒng)通過(guò)CodeList進(jìn)行文字和代碼的轉(zhuǎn)換

12. LRU：Least Recent Used的縮寫，是一種簡(jiǎn)單的緩存策略，如果緩存已滿，那么就釋放最近最少使用的那個(gè)緩存數(shù)據(jù)

13. REST：是REpresentational State Transfer的縮寫，是一種基于輕量級(jí)WebService協(xié)議

四、客戶端數(shù)據(jù)處理的技術(shù)場(chǎng)景

在本部分里將會(huì)針對(duì)下面六個(gè)分類對(duì)客戶端數(shù)據(jù)處理的技術(shù)場(chǎng)景進(jìn)行概述

• 數(shù)據(jù)綁定（Data Binding）

• 數(shù)據(jù)變更追蹤（Data Change Tracking）

• 數(shù)據(jù)訪問(wèn)（Data Access）

• 數(shù)據(jù)緩存（Data Caching）

• 數(shù)據(jù)查詢（Data Query）

• 數(shù)據(jù)處理（Data Processing）

4.1 數(shù)據(jù)綁定（Data Binding）

概念：

以非常簡(jiǎn)單的聲明方式實(shí)現(xiàn)Form、Grid這種數(shù)據(jù)填寫、修改構(gòu)件與數(shù)據(jù)之間的對(duì)應(yīng)關(guān)系。

場(chǎng)景：

• Form綁定：把一個(gè)Form與一個(gè)數(shù)據(jù)對(duì)象通過(guò)聲明的方式綁定，使得Form的修改直接可以體現(xiàn)在數(shù)據(jù)對(duì)象中，而數(shù)據(jù)對(duì)象的修改也可以馬上由Form體現(xiàn)出來(lái)

• Grid綁定：把一個(gè)Grid和一個(gè)數(shù)據(jù)對(duì)象集合通過(guò)聲明或者設(shè)置數(shù)據(jù)源的方式綁定，使得在Grid上的寫操作都可以體現(xiàn)在數(shù)據(jù)對(duì)象集合中，而數(shù)據(jù)對(duì)象集合的操作也可以馬上由Grid構(gòu)件體現(xiàn)出來(lái)

• Tree綁定：由于Tree的特殊性，與其說(shuō)Tree與一個(gè)數(shù)據(jù)對(duì)象集合綁定，不如說(shuō)Tree使用了一個(gè)可以根據(jù)查詢提供數(shù)據(jù)的數(shù)據(jù)來(lái)源更合適。當(dāng)然，由于Tree有可能被可視化的修改（如組織機(jī)構(gòu)管理），所以這個(gè)數(shù)據(jù)來(lái)源必須支持對(duì)數(shù)據(jù)的寫操作

• 其它：如菜單的綁定等，相對(duì)于上述三個(gè)都屬于非常用的綁定，而且如果上述綁定能夠?qū)崿F(xiàn)，那么其他的綁定也可以采用同樣的技術(shù)實(shí)現(xiàn)

 4.2 數(shù)據(jù)變更追蹤（Data Change Tracking）

概念：

對(duì)數(shù)據(jù)的整個(gè)生命周期進(jìn)行追蹤。主要的目的就是可以通過(guò)記錄看出數(shù)據(jù)做了哪些改變，然后根據(jù)這些改變做出相應(yīng)的處理，其使用場(chǎng)景有Grid的變更提示、Form修改的追蹤等。

場(chǎng)景：

• Grid變更提示：在Grid中以明顯的方式提示用戶做了哪些修改

• 數(shù)據(jù)集合變更追蹤：根據(jù)變更的效果，可以有選擇的發(fā)送合適的數(shù)據(jù)給服務(wù)端進(jìn)行處理

• Form修改的追蹤：為用戶在提交Form時(shí)提示用戶哪些重要的字段進(jìn)行了修改提供支持

4.3 數(shù)據(jù)訪問(wèn)（Data Access）

概念：

服務(wù)端與客戶端數(shù)據(jù)傳輸?shù)母袷轿幢叵嗤?，而且?shù)據(jù)對(duì)象屬性的類型等信息也需要一些Meta Data API來(lái)進(jìn)行支持。所以，抽象出一個(gè)抽象的擁有Meta Data的數(shù)據(jù)訪問(wèn)層是有意義的。

場(chǎng)景：

• 數(shù)據(jù)對(duì)象元數(shù)據(jù)信息訪問(wèn)：可以通過(guò)這些元數(shù)據(jù)信息了解數(shù)據(jù)對(duì)象的各個(gè)屬性以及對(duì)應(yīng)的數(shù)據(jù)類型（這一點(diǎn)對(duì)于Json格式的數(shù)據(jù)傳輸尤其重要，因?yàn)?/strong>Json規(guī)范里面沒(méi)有DateTime類型）

• 數(shù)據(jù)寫操作的統(tǒng)一事件定義：通過(guò)Data Access API來(lái)訪問(wèn)數(shù)據(jù)，所有的寫操作都會(huì)有統(tǒng)一的事件定義，在JavaScript 1.5中，普通的JavaScript對(duì)象是做不到的

• 統(tǒng)一的數(shù)據(jù)讀取方式：不管數(shù)據(jù)是XML格式的還是Json格式的，訪問(wèn)數(shù)據(jù)的方式都是統(tǒng)一的

4.4 數(shù)據(jù)緩存（Data Caching）

概念：

數(shù)據(jù)緩存是指把獲得的數(shù)據(jù)以一定的策略緩存起來(lái)，以備使用的技術(shù)。Cache是客戶端數(shù)據(jù)處理中涉及到功能和性能的重要部分，原因請(qǐng)見(jiàn)下面的場(chǎng)景

場(chǎng)景：

• 離線運(yùn)行的CodeList：系統(tǒng)如果需要離線運(yùn)行，那么CodeList肯定需要客戶端緩存

• 離線表單填寫：如果允許用戶離線填寫表單，那么需要采用客戶端緩存策略保存用戶的數(shù)據(jù)

• 性能考慮：向服務(wù)端發(fā)請(qǐng)求，服務(wù)端查詢并返回屬于非常耗費(fèi)資源和時(shí)間的操作，所以對(duì)于服務(wù)端的數(shù)據(jù)，客戶端應(yīng)該有一定的緩存以及同步策略

4.5 數(shù)據(jù)查詢（Data Query）

概念：

數(shù)據(jù)查詢的概念非常簡(jiǎn)單，根據(jù)用戶的查詢條件向服務(wù)端發(fā)送查詢請(qǐng)求，得到服務(wù)端返回的數(shù)據(jù)對(duì)象集合。

但由于數(shù)據(jù)查詢是系統(tǒng)中最常用的功能，所以，數(shù)據(jù)查詢需要非常強(qiáng)大的功能。簡(jiǎn)單列舉如下。

場(chǎng)景：

• 樣本查詢：給出一個(gè)樣本，比如{age : 20, gender : 'male'}，返回所有符合樣本的結(jié)果

• 模糊查詢：用戶可以提供非明確的查詢參數(shù)（如李？？，查詢所有姓李的，名字為三個(gè)字的人），返回結(jié)果供用戶進(jìn)一步的篩選

• Range查詢：根據(jù)Start Index和Count返回整個(gè)大數(shù)據(jù)集中的一部分，一般用在分頁(yè)查詢處理方面，當(dāng)然也可以用在其他的需要整個(gè)數(shù)據(jù)集的一部分的地方

• 邏輯查詢：采用邏輯操作對(duì)數(shù)據(jù)進(jìn)行過(guò)濾查詢，比如（employee中所有滿足age < 40 && age >30 && gender = ‘male’ && married條件的員工——年齡大于30且小于40的已婚男員工），實(shí)際上上面所說(shuō)的查詢都可以以某種方式歸為邏輯查詢的一種，之所以明確的提出來(lái)，是因?yàn)椴樵兊恼Z(yǔ)法有可能有所不同，并且有些構(gòu)件或者服務(wù)會(huì)對(duì)某些查詢有特別的需求或者加強(qiáng)的支持以簡(jiǎn)化開(kāi)發(fā)的難度，提高開(kāi)發(fā)的效率

• 自定義查詢：根據(jù)用戶的需要可以對(duì)上面的查詢進(jìn)行有機(jī)地結(jié)合

4.6 數(shù)據(jù)處理（Data Processing）

概念：

在數(shù)據(jù)查詢、顯示、修改和持久化的過(guò)程中，用戶有可能還需要做一些監(jiān)控，以及一些自定義的操作，如過(guò)濾、排序等。這就需要一套數(shù)據(jù)處理的事件以及數(shù)據(jù)處理的方法。這些統(tǒng)一歸到數(shù)據(jù)處理用例中。列舉如下。

場(chǎng)景：

• 數(shù)據(jù)處理事件：數(shù)據(jù)的查詢以及持久化過(guò)程中的事件

• 數(shù)據(jù)過(guò)濾：通過(guò)數(shù)據(jù)過(guò)濾（查詢前、查詢后）可以滿足權(quán)限控制等功能的要求

• 排序：可以對(duì)數(shù)據(jù)進(jìn)行自定義的排序（查詢、查詢結(jié)果

五、小結(jié)

客戶端的數(shù)據(jù)處理能力是客戶端最主要的基礎(chǔ)能力，它直接影響到了應(yīng)用服務(wù)器的負(fù)荷以及用戶UI響應(yīng)的速度和效率。所以，客戶端的數(shù)據(jù)處理支持是一個(gè)RIA平臺(tái)非常重要的考核點(diǎn)?？梢陨厦娴牧悎?chǎng)景去考核各種RIA平臺(tái)，同時(shí)，它們也為我提出我的RIA客戶端數(shù)據(jù)處理解決方案提供了基礎(chǔ)的用例。

posted @ 2007-12-08 10:31 guitarpoet 閱讀(1706) | 評(píng)論 (2) | 編輯 收藏