最近在求職，耽擱了，對於應屆生來講想找個大資料相關的工作何其困難。。。
所以在填充一些自己不足之處，希望與君共勉。
開發過程中，如果發現客戶程式依賴某個(或某類)物件，我們就通常會對他們進行一次抽象，形成抽象類、介面。這樣，客戶程式就可以擺脫所依賴的具體型別。
那麼「誰」擔任這個重擔呢？其實，很多時候建立型模式可以輕易的解決這個問題。但如果設計的不是具體業務邏輯，而是公共庫/框架，這時候很多半成品的外部型別例項會在我們的管理下執行，如何把這些外部型別所需的抽象型別傳給他們就成了新問題。
這個場景也就是常說的「控制反轉」，ioc：inverse of control；框架程式與抽象型別的呼叫關係就像常說的好萊塢規則「don』t call me,i』ll call you」，即，由ioc容器幫物件找相應的依賴物件並注入，而非物件主動去找。
ioc 容器控制了物件，主要控制了外部資源獲取(不只是物件，包括檔案等)。
ioc反轉，由容器幫我們查詢及注入依賴物件，物件是被動的接受依賴物件，所以是反轉。
"依賴注入"的方式：將加工好的抽象型別例項「注入」到客戶程式中。
ioc對程式設計的改變是在思想上，發生了「主從換位」的變化。
構造注入方式又稱「構造子注入」、「建構函式注入」，這種注入方式就是在建構函式的執行過程中，通過assembler或其他機制把抽象型別作為引數型別作為引數傳遞給客戶型別。這種方式雖然相對其他方式有些粗糙，而且僅在構造過程中通過「一錘子買賣」的方式設定好，但很多時候我們設計上正好就需要這種「一次性」的注入方式。
設值注入是通過屬性方法賦值來實現的，set(…)。
相對構造方式而言，設值注入給了客戶型別後續修改的機會，它比較適合客戶型別例項存活時間較長的情景。
介面注入是將抽象型別的入口以方法定義在乙個介面中，如果客戶型別需要獲得這個方法，就需要以實現這個介面的方式完成注入。
實際上介面注入有很強的侵入性，除了要求客戶型別增加前面兩種方式所需實現的**外，還必須顯式的定義乙個新的介面並要求客戶型別實現它，
在assembler和客戶型別中選擇，為了客戶物件影響最小，我們只好在assembler上下功夫，因為他的職責就是負責組裝。反而言之，如果注入過程還需要修改客戶程式，那我們就沒必要去用「依賴注入」了。
但是在實際專案中，由於屬性注入處理不好會導致執行效率低(每次例項化物件都需要對映)和對客戶端的侵略性，我們要慎重使用。
構造方式
他的注入是一次性的，當客戶型別構造的時候就確定了
他適合生命期不長、在其存續期間不需要重新適配的物件
設值方式
乙個很靈活的實現方式
對於生命週期較長的客戶而言，可以在執行過程中隨時注入
屬性方式
作為注入方式具有入侵性，很大程度上他適於需要同時約束一批客戶型別的情況
他本身實現相對複雜一些，但客戶型別使用的時候非常方便–「打標籤」即可
介面方式
作為注入方式具有入侵性，很大程度上他適於需要同時約束一批客戶型別的情況
但是c#中使用泛型可以減少其入侵性
注入方式
具有入侵性，很大程度上他適於需要同時約束一批客戶型別的情況
但是c#中使用泛型可以減少其入侵性
常見Spring依賴注入的兩種方式
設定注入 ioc容器使用屬性的setter方法來注入被依賴的例項。構造注入 ioc容器使用構造器來注入被依賴的例項。兩種方法的 比較 設定注入 private string name private string password private void setname string name 同...
SQL注入的常見方式及測試方法
本文主要針對sql注入的含義 以及如何進行sql注入和如何預防sql注入讓小夥伴有個了解。適用的人群主要是測試人員，了解如何進行sql注入，可以幫助我們測試登入 發布等模組的sql攻擊漏洞，至於如何預防sql注入，按理說應該是開發該了解的事情 但是作為乙個棒棒的測試，搞清楚原理是不是能讓我們更加透徹...
HW常見攻擊方式 SQL注入漏洞
年輕的時候愛上什麼都不為過，成熟了以後放棄什麼都理解，我們終其一生，不過是想找乙個能一起吃飯的人。網易雲熱評 一 產生原因 與資料不區分。程式把使用者輸入的惡意內容傳入sql語句中執行,導致sql注入漏洞產生。二 常見挖掘方式 直接對url中的引數 請求引數 請求頭 進行注入 burp抓取post包...