工做那些事兒（11）- 數據集成

    雖然我只負責前端的開發，可是我也一樣關心後臺的數據集成的實現方式，由於我但願那能按我以前的總體設想進行。

    幸運的，老H同志竟然能理解我以前跟他說的思路，他最後仍是跟我想到一個點上了。因爲如今先後端完全分離了，因此相似structs這樣的頁面跳轉的MVC控制實際上是不須要了（實際上mvc交給前端作了），而數據集成實際上是面向各個企業內部系統去取數，自己對數據庫要求很低，是輕數據庫型應用，所以hibernate也是不須要的，spring也太龐大無用武之地。最後後臺的數據集成用了最簡單最純粹的servlet，很合我口味。其實就是經過servlet暴露了獲取數據的接口供前端調用，而後根據調用參數，決定去哪一個系統調用什麼數據。

    固然，這裏仍是有一些設計技巧的，實際上老H又一次跟我想到一塊兒，就像我前端想作相似Ioc的效果同樣，後臺也須要，由於數據接口只有1個，根據調用參數不同，須要運行時決定實例化哪個類來進行數據抽取工做。這裏老H沒有用spring ioc，而是直接用了最直接的class loader，並經過接口化編程模型，爲後來的二次開發肯定了編程接口。然後全部新增的數據集成類咱們都稱之爲一個data provider。

    provider的具體實現方式，有幾種，有些系統提供了接口，譬如OA，之前就專門爲EIP開發了接口，因此EIP只要調用接口就能夠獲取到數據了，譬如代辦列表，公告列表等；有的系統是提供了數據庫視圖訪問，這些也就直接用jdbc去訪問數據庫視圖便可，譬如一些統計數據指標；還有一些，既沒接口又沒有數據庫視圖的，咱們就經過抓頁面的方式，主動出擊。要知道，在企業的環境下，有不少遺留系統，有不少合同的考慮，一些作好的系統未必能立刻就給你開發新接口，要等的話就不靠譜了，因此抓頁面是一個很主動的手段，不求人，但弱點是，假設被集成的系統頁面結構一變化，而抓取的代碼不夠健壯的話，就會失效。幸虧這樣的狀況在企業裏出現的概率較低，通常系統上線穩定後都不會改了。

    後臺的基本框架就這樣定下來了。老H仍是有比較強的編碼能力的，這東西也沒作多久就出來了。就這樣，沒多久咱們就先後臺一塊兒聯調了。此次合做仍是比較順利的。