經過一週的時間和構思，終於將XX專案的最後個尾巴給解決掉了，在這裡值得鼓勵一下，但是還有些不足，希望記錄下來，以後遇到諸如此類問題可以做個參考或者是程式設計思維上的不斷進步也好。

需求描述：由於本系統開發是有我全部開發的一個數據全部要對接XX平臺的資料，本系統的核心資料全部是來源於此平臺的Excel表，所以每次到資料的工作是由我完成的，但是此工作我只能幹一段時間，所以最終還的交予使用者定期去處理。

問題描述：同步資料的時候，時間會很長，這中途如果有錯誤資訊，或者一系列的操作是需要客戶去等待同步完資料才可以進行下一步操作的，這個時間需要大概10來分鐘，在這個時間段，客戶是無法得知更新情況的，在傳統的實現方案中，必須得等伺服器處理完才可以。

初步解決方案：利用Java的網路程式設計websocket實現，首先客戶端和伺服器建立一個長連線，由伺服器每次向客服端動態的推送資料，報告給客戶每一步執行的情況。

這一原理並不複雜，並且結合自己之前寫的聊天室，基礎框架基本能搭建出來。首先實現了伺服器向客戶端傳送訊息，不錯，還是搭建起來了，但是不成想邏輯是走通了，但是在spring整合socket的時候，卻出現了服務注入不進去的問題。就這個問題糾結了二天。

首先：到網上查了很多資料，網上遇到這類問題的小夥伴還是真不少，那咋辦呢，找著別人踩坑，爬坑的經歷再來一遍吧。可是我的哥哥喲，居然每一個能解決的，真是網路上的東西有幾個能實際解決問題的，不經在問，現在的百度除了競價排名，還能幹什麼，此時問題還尚未解決，但是時間卻浪費在這蛋疼的問題上了。

那咋辦呢，拋棄吧，要不直接上JDBC吧，好吧似乎也只能這樣了，好那就直接上JDBC,拍拍。。。一頓程式碼上，終於和資料庫又一次的進行了友好的連線，可是資料表字段太多了，三四十個，但是沒辦法，現在也只能只有了。。。。終於寫完了，哈哈，還不錯。但是問題又來了，似乎今天就是和我過不去，資料太亂了，亂的我毫無防備，此時裡面的欄位是有些是空的，噢噢噢，忙的把這事給忘了，原理使用mybatis的時候是把每個進行欄位非空判斷的，現在使用jdbc了，雖然好幾年不用jdbc了，但是我想非空判斷不是個問題吧。不會找度娘，又是一頓找度娘，可是除了一些最基本的jdbc的操作，要不就是一些對jdbc的簡單的封裝，似乎真的沒有什麼用。現在我腦子裡閃現出何不用jdbc封裝物件，然後用jdbc操作物件的方式將其插入完後再物件的層面做非空判斷，此時不是很很好嘛。哎呀 我真是佩服我自己，什麼招都能用上，可是，jdbc封裝物件的案例實現是少的可憐，終於找到了一個案例，經過測試還能使用，可是不滿足我的要求了。好吧，自己改原始碼吧，哎呀。改了半天我都要崩潰了，什麼了都是。。。。。。越改越亂。我放棄了。

此時，我徹底絕望了，不能用此方法了，我發現自己已經進入了一個死衚衕裡出不來了，如果解決問題還應該儘快的跳出來，此時我鼓足了勇氣向我的專案總監進行請求，然後經過交流，我的專案總監給我的建議是不用websocket，可是我的那個需求就要大大打折扣，也不是我最終想要的那個結果。此時我發現還應該堅持一下，好吧，休息休息吧。

終於一個突然的想法引入我的腦海中，我想，我還是應該回到問題的本身。問題的本身是什麼？

我不斷的再發問，問題的本身，就是socket引入之後通過 @Autowired 注入是完全注入不進去。

此時我再想，之前初接觸spring的時候，是通過spring手工注入的方式注入的，那麼既然框架本身注入不進來，我就手工注入，好說幹就幹， 哈哈哈哈哈哈哈。。。終於注入進來了，所有問題都迎刃而解。

通過解決這個問題進行的反思有以下幾點，希望以後再生活和工作中有個參考，也是我此次寫此部落格的目的，希望與諸君共勉。

1、再解決某個需求是要善於從框架內跳出來。（生活中，更是，在生活中沒有固定的答案，想要真正的幹一些事情，墨守成規雖然是一種有時候是一種明哲保身的為人處世之道。）

2、在處理問題和日常生活中不要一味地去相信權威，相信權威是學習，過度的相信權威是盲從，盲動。

3、在學習和接觸新事物中，我們常常去本著“是什麼-為什麼-怎麼辦”的思維去構建我們的認知系統，但是，在進入網際網路時代我們的這種認知系統有時候是被打破的，有時候 是什麼是發生在為什麼和怎麼辦之後的，因為是什麼是伴隨著為什麼，怎麼辦的不斷去加深的和理解的，而為什麼似乎不是問題的焦點，這大概是市場的作用吧，也是市場和學校的本質區別吧 。

4、在處理問題的時候，要把問題看的通，看的明白，不要被表象所迷惑了，遇到事情多在腦子裡問一問為什麼，為什麼這樣，而不是那樣，但是要達到這一步必須得多思考，多實踐，畢竟“紙上得來終覺淺，絕知此事要躬行”。