最近有一個自動獲取微博資料的專案中要求自動獲取指定微博中相關的評論來做分析（1期時暫只有sina微博），最早由我來設計程式結構和資料庫，當然同時也是由我來開發，但是我做出來的東西最終沒有的到我同事的認可（我認為我的程式只是簡單的獲取資料，但是其他的同事可能有他們的想法，他們認為程式還應該包含部分資料分類，當然我不反對這樣的設計，我的程式也支援這樣的做法）所以在程式開發完成後，我被迫將專案給了另外一位同事繼續（按照我最初的設計，我交出的版本已經可以使用的最終版本）。之後修改成什麼樣子了我不得而知。今天聽聞明天那位同事就要去討論微博程式。我才想起我之前的設計，在我看來這個設計也有他獨到之處，雖然最後被其他同事否決，但是他的優勢也是顯而易見的，所以我在這裡寫一些設計思想，希望明天討論時也能作為一個選項。

一、設計思想

    我最早獲得的需求是希望按時按指定的條件自動獲取微博資訊使用者業務部門的資料分析，當然最早只有Sina的資料，之後可能還會繼續上騰訊天涯等資料。為了滿足這個需求我設計時將“目標的資料結構”（Sina就是json物件包含的欄位），本地的“實體類”，和對應的“資料庫表”，實現執行介面物件，4個物件對映關聯起來。簡單的講就是，通過實現了實現了“執行介面”的物件獲取目標資料後，轉換為本地實體，之後再存入對應的表，表結構和目標資料返回的機構一致，這樣就能最大限度的儲存最原始的資料，只要有了原始資料其他業務部門希望怎麼處理都可以了，我最早的設計和其他同事衝突點也在這裡，我認為我的程式就是簡單的將目標站點的資料不加處理的存入對應表，但是其他同事認為，獲取的資料還必須進行必要的篩選處理（當然我前面也說了我設計的執行物件中本身是支援這樣做法的，只是我覺得沒有必要，我們的程式應該只要完成必要的資料獲取就可，處理資料應該留給業務層）。最後在說明一點其實最最早的設計中我連對應的表都是沒有的，只有一張物件結構表，用來儲存物件的結構資料，獲取目標物件後將資料以垂直表方式存放（好處是擴充套件性極高，因為不需要預先確定表結構），這個設計在一開始就遭到我同事猛烈反對，所以之後才設計了用固定表結構來對應目標資料結構。

二、資料庫設計

資料庫設計包含很多張表，關係到系統結構的包含：

資料查詢計劃表（WebSiteTable）:

TableName 實體對映表名

Url 獲取目標資料Url

Class 對應實體物件

通過這個表的這3個欄位，我可以將目標資料和本地實體資料庫關聯，程式每次獲取這張表資料，可以知道應該訪問的目標地址，返回後該用什麼物件處理，又該存到那張表中

引數組關聯表（ParameterSetting）

WebSiteTableID 是那個查詢的引數

NextExecTime 此引數下次執行時間

這張表用來關聯某個查詢關聯的引數列表，一個查詢計劃（WebSiteTable）可以對應多條此表記錄，此時代表這個執行計劃有多個條件組合。比如查詢關鍵字時需要傳入“使用者名稱”，“關鍵字”兩個引數，而關鍵字是有多個的且不同的，這個時候你可以在這張表中建立多個關聯，關聯到

引數表（Parameter）

ParameterSettingID 引數關聯編號

Key 引數名

Value 引數值

這張表就是存具體引數的表。它關聯ParameterSetting表，也就是這個表中引數組對應的具體引數，他是以鍵值對的方式儲存的。

程式執行過程

1、程式讀取WebSiteTable獲取要執行的計劃

2、通過WebSiteTableID獲取這個執行計劃需要的引數列表

3、反射建立WebSiteTable表中Class欄位對應物件

4、用創建出來的執行物件（必須繼承IEntityBase介面下文會提及）開始執行查詢

5、獲取資料並呼叫IEntityBase物件處理後續。

6、記錄Log(log會記錄每一條資料是用什麼條件在何時獲取的)

三、程式設計

1、資料庫操作

資料庫操作程式設計使用了之前在彩信系統中使用的資料庫實體操作類，也就是隻需要配置好實體就可以自動多表關聯查詢儲存新增等處理操作，這個不是本文關鍵所以只簡單介紹一下。

這個東西是在彩信專案中開發的，使用者建立實體後，通過對應特性頭，可以關聯這個實體對應的表，以及執行更新時需要呼叫的儲存過程。當然這個實體支援多表關聯查詢，支援鏈級更新等，具體可以參考彩信系統。

2、執行介面

獲取程式提供一個介面（IEntityBase）這個介面必須實現Send方法和Receive方法

Send：方法會將資料庫中對應的執行引數資訊作為傳入，這個方法會在正式傳送前被呼叫，你可以在這個方法中處理引數資料，之後傳送模組就會配置資訊和引數進行傳送。

Receive：方法在接受完資料後會呼叫此方法，他會傳入獲取這條資料時用的引數列表和獲取的資料兩個引數，你可以在這個方法中處理獲取到的資料比如，將資料分發到不同的表（因為程式使用了彩信系統中開發的資料物件處理類所以你只要關聯設定實體就可以鏈級更，這也是我之前為什麼說當時和其他同事爭論設計時我說我的設計同時相容他們的想法的原因，當然最後我的設計還是被拋棄了）

每個實體都必須繼承並實現這兩個方法，之後將這個實體物件，資料表和目標Url在關聯表中關聯起來就能完成實現資料轉換了！

    當然程式還有一個迴圈過程每次通過訪問資料庫獲得查詢條件之後不斷的執行。

    這個設計總體來講就是希望將資料表，物件和遠端物件關聯在一起，因為執行過程的統一，之後的擴充套件性也是可以預見的，之後如過需要新增新的資料獲取物件和對應的關係就可。

    雖然這個東西最後被其他同事否決，我最終也沒有繼續去做這個專案，但是這個設計我覺得還是有他獨到的特點的，我也希望大家可以認同我的設計，也希望我的介紹可以給大家帶來帶新思路，幫助大家完成設計。