春天是屬於懶人的。基礎知識、基本概念和帶有程式碼的範例。第1部分

許多人在閱讀了我有關為Web 專案建立範本以及使用 servlet 建立簡單 Web 服務的文章後，想知道我什麼時候會寫有關 Spring 的文章。我不想，我建議看一本書（我仍然說一本書比網上10篇，甚至100篇文章要好）。但現在我決定向不同的人解釋同樣的事情，我花的時間比坐下來寫一篇文章，然後只是發布一個連結要多。所以我寫這篇文章是為了連結））。 在本文中，我不會按照我的範例，在 5 分鐘內編寫如何在 Spring 中建立一個工作項目。 我只會寫一些基本的事情，如果不了解這些知識，當然可以啟動一個項目，但那裡發生的事情，更重要的是，為什麼，將不清楚。

什麼是 Spring 框架？

Spring Framework或簡稱Spring是用 Java 創建 Web 應用程式的最受歡迎的框架之一。框架類似於庫（也許這個術語你更熟悉），但有一點。粗略地說，使用庫，您只需創建其中的類別的對象，調用您需要的方法，從而獲得您需要的結果。也就是說，有一種更命令的方法：你在程式中明確指出在什麼特定時刻需要創建哪個對象，在什麼時刻需要呼叫特定方法等。對於框架，情況略有不同。您只需編寫一些自己的類，在那裡編寫一些邏輯，框架本身就會創建您的類別的物件並為您呼叫方法。大多數情況下，您的類別實作框架中的一些介面或從中繼承一些類，從而接收一些已經為您編寫的功能。但事實並非一定如此。例如，在 Spring 中，他們嘗試盡可能地擺脫這種嚴格的耦合（當您的類別直接依賴該框架中的某些類別/介面時），並為此目的使用註釋。我們稍後會回到這一點。但重要的是要了解Spring只是一組已經為您編寫的類別和接口:) 我還想立即指出 Spring 不僅可以用於 Web 應用程序，還可以用於最常見的控制台我們所有人都熟悉的應用程式 今天我們甚至會寫類似的東西。

結構

但 Spring 並不是一種特定的框架。這是許多小型框架的通用名稱，每個框架都執行某種不同的工作。 正如您所看到的，彈簧具有模組化結構。這允許我們僅連接應用程式所需的模組，而不連接那些我們顯然不會使用的模組。據我所知，正是這種做法幫助Spring超越了當時的競爭對手（EJB）並取得了領先地位。因為使用EJB 的應用程式有很多依賴關係，而且一般來說它們變得緩慢且笨拙。 從圖中可以看出spring框架由幾個模組組成：

• 資料存取；
• 網路；
• 核;
• 和別的。

今天我們來熟悉一下主模組的一些概念，例如：bean、context等。正如您可能猜到的那樣，資料存取模組包含用於處理資料（主要是資料庫）的工具，用於在網路上工作的Web （包括用於建立 Web 應用程序，這將在稍後討論）。此外，還有所謂的整個 Spring 基礎設施：許多其他專案並未正式包含在框架本身中，但無縫整合到您的 Spring 專案中（例如，用於在 Spring 上處理使用者授權的相同 spring security）

為什麼選擇 Java 中的 Spring？

嗯，除了它時尚、時尚、年輕之外，我可以立即說，只要你稍微掌握它，你就會明白你現在不需要做多少不同的工作，還有多少春天承擔。您可以編寫幾十行配置，編寫幾個類別 - 然後您將獲得一個工作項目。但是，一旦您開始思考“幕後”有多少內容，正在完成多少工作，以及如果您在裸 servlet 或套接字和純 Java 上執行相同的項目，則必須編寫多少代碼- 你的頭髮都豎起來了:) 甚至還有這樣的表情，就像春天的「魔力」一樣。這是當你看到一切都在工作時，但你粗略地估計了那裡必鬚髮生多少事情才能讓一切正常工作以及一切如何在那裡工作- 然後似乎所有這一切的發生都歸功於某種魔法真的））更容易稱其為魔法，而不是試圖解釋它們是如何相互關聯的。:) 嗯，「支持」學習Spring 的第二個論點是，在大三的大約90% 的職位空缺中（根據我個人的觀察），要么是知識，要么至少是對Spring 的君子集有一個大概的了解data，web-mvc以及security:) 只需要基礎知識。

DI/IoC

如果您嘗試閱讀有關 Spring 的內容，那麼您首先遇到的可能是這些字母：DI/IoC。現在我強烈建議您暫時放下這篇文章並閱讀這篇關於 Habré 的文章！ IoC（控制反轉） ——控制反轉。當我寫到使用函式庫時，你自己在程式碼中寫要呼叫哪個物件的哪個方法時，我已經順便提到了這一點，而對於框架來說，大多數情況下框架會呼叫你在右側寫的代碼片刻。也就是說，在這裡您不再控制執行程式碼/程式的過程，而是框架為您完成。您將控制權轉移給了他（控制反轉）。DI可以理解為Dependency Inversion （依賴倒置，即嘗試不在模組/類別之間建立硬連接，其中一個類別直接綁定到另一個類別），或Dependency Injection（依賴注入，這是當 cat 物件不由你在main 中創建，然後將它們傳遞給你的方法，Spring 為你創建它們，你只需告訴他類似“我想在這裡養一隻貓”，他就會在你的方法中將其傳遞給你） 。我們將在以後的文章中更經常地遇到第二個。

Bean 和上下文

Spring 的關鍵概念之一是bean。本質上，它只是某個類別的物件。假設我們的程式需要使用 3 個物件：一隻貓、一隻狗和一隻鸚鵡。我們有一堆帶有一堆方法的類，有時我們需要一隻貓作為一個方法，一隻狗作為另一個方法，有時我們會有需要一隻貓和一隻鸚鵡的方法（例如，一個方法用於餵養貓，呵呵），在某些方法中，將需要所有三個物件。是的，我們可以先在main中創建這三個對象，然後將它們傳遞給我們的類，再從類內部傳遞給我們需要的方法……以此類推整個程序。如果我們還想像我們想要定期更改我們的方法接受的參數列表（好吧，我們決定重寫一些東西或添加功能） - 那麼如果我們需要的話，我們將不得不對程式碼進行大量編輯更改些什麼。現在，如果我們想像我們擁有的不是 3 個而是 300 個這樣的物件怎麼辦？另一種方法是將所有此類物件收集到一個公共物件清單 ( List<Object> ) 中，並將其傳遞給所有方法，然後從方法內部取得我們需要的這個或那個物件。但是，如果我們想像隨著程式的進行，某些物件可能會被添加到這個清單中，或者（更糟的是）被刪除呢？然後，在我們透過索引從清單中檢索物件的所有方法中，一切都可能會中斷。然後我們決定儲存的不是一個列表，而是一個映射，其中鍵是我們需要的物件的名稱，值是物件本身，然後我們可以透過名稱從中取得我們需要的物件: get(" parrot")作為回應，我們收到了一個對象parrot 或者說，鍵是物件的類，值是物件本身，那麼我們可以不再指示物件的名稱，而只需指示我們需要的物件的類，這樣也方便。或者甚至在映射上編寫某種包裝器，您可以在其中創建方法，以便在某些情況下您可以按名稱檢索對象，而在其他情況下則可以按類別檢索對象。這是我們從 spring應用程式上下文中得到的。上下文是一組 bean（物件）。轉向上下文，例如，我們可以透過名稱、類型或其他內容來取得所需的 bean（物件）。此外，我們可以要求 Spring 在其上下文中找到我們需要的 bean 並將其傳遞給我們的方法。例如，如果我們有這樣的方法：

public void doSomething(Cat cat) {
    ...
}

當 Spring 為我們呼叫這個方法時，它將我們的貓的物件從它的上下文傳遞給它。現在我們決定我們的方法除了貓之外還需要一隻鸚鵡。使用彈簧 - 對我們來說沒有什麼比這更容易的了！我們簡單寫：

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

當Spring呼叫我們的這個方法時，它會明白我們需要在這裡傳遞一隻貓和一隻鸚鵡，進入它的上下文，獲取這兩個物件並將它們傳遞給我們的方法。透過將程式的控制權移交給 Spring，我們還將創建物件並將其傳遞給他將呼叫的方法的責任轉移給了他。問題出現了：Spring 如何知道要建立哪些物件（bin）？

應用程式配置方法

配置應用程式有三種主要方法（即告訴 Spring 我們需要工作哪些物件）：

1. 使用 xml 檔/配置；
2. 使用java配置；
3. 自動配置。

Spring 開發人員會依照以下優先順序排列它們：

• 應優先考慮的最優先方法是自動配置；
• 如果使用自動配置無法正確配置所有可能的 bean，請使用 Java 配置（使用 Java 程式碼建立物件）；
• 嗯，優先順序最低的方法是老式方法，使用 xml 配置。

此外，Spring 允許您組合這些方法。例如，讓 Spring 完成所有可以自動設定的事情；在需要指定一些特殊參數的地方，使用 Java 配置來完成，此外，您還可以以 xml 格式連接一些遺留配置。一般來說，這一切都可以相當靈活地完成。但是，如果一切都可以使用自動設定完成，請使用它。我只會考慮自動配置和 Java 配置；xml 配置已經在互聯網上的幾乎每個 Spring 範例中使用，一旦您了解了 Java 配置的工作原理，「讀取」執行相同操作的 xml 檔案應該沒有問題。當我們工作所需的物件是我們編寫的類別的物件時，使用自動配置。如果需要一些非常具體的邏輯來建立類別的對象，或者如果我們沒有機會使用我們需要的註釋來標記某些類別（自動配置會拾取這些註釋），則可以在 Java 配置中完成。在下一部分中，我們將建立一個 Maven 項目，將幾個中央 spring 模組連接到它並建立我們的第一個 bean。