面對現實吧，有兩種開發人員：支援spring自動裝配的開發人員，因為它減輕了他們編寫xml的負擔（即使您可以使用xml進行自動裝配），以及那些將自動裝配視為危險的開發人員。
我必須承認我屬於第二品牌。 實際上，我寧願面對800磅重的大猩猩，也不願使用自動裝配。 當然，這為您完成了所有工作，不是嗎？ 也許吧，但這是一項艱苦的工作，我寧願弄髒我的手，也不願讓一些廉價的機械人替我做這件事。 問題的根源在於自動裝配的隱含性 。 您宣告兩個bean，說乙個需要另乙個，然後我們離開。
在紙上看起來很簡單，那就是我們是否允許這樣做。 現在，自動裝配有兩種主要方式：
前者雖然相對良性，但可能導致命名夢night，開發人員將調整名稱以使其自動裝配在一起。 第二個完全是胡說八道：在這種情況下，您可以在工作上下文中通過在其中建立乙個bean來產生問題，這僅僅是因為它具有與上下文中已經存在的另乙個bean相同的類。 更糟糕的是，自動佈線錯誤可能會在乙個完全不相關的位置發生，這僅僅是因為自動佈線涉及的魔力。 不，解決方案不是混合使用自動裝配和顯式裝配，在名稱和型別之間混合使用自動裝配，甚至不將bean排除在自動裝配的候選物件之外。 由於開發人員不得不不斷地質疑行為是什麼，這只會加劇複雜性。
不確信的自動佈線風扇應閱讀spring文件本身，以獲取限制和缺點的列表。 這並不是說自動佈線本身是不好的，只是必須嚴格控制。 到目前為止，我只允許小型團隊和測試使用（ 即，**不會交付生產）。
cdi開發人員應該暗示我要去的地方。 由於在cdi中，類路徑上的每個類都是自動裝配的候選物件，因此這意味著在應用程式的類路徑上新增新的jar可能會破壞cdi並阻止應用程式啟動。 因此，對於cdi，僅應使用名稱自動佈線...然後，只有勇於冒險的人才能使用di
翻譯自:
Spring自動裝配
先在cn.csdn.hr.dao包中建立幾個檔案 public inte ce basedao public class basehibernatedaoimpl implements basedao public inte ce customerdao public class customerd...
Spring自動裝配
通常情況下，配置bean的時候，一些屬性依賴需要我們自己去裝配，但是如果這是乙個比較大型的工程，裡面定義了成百上千個bean，那全都靠我們手工去裝配，你一定打心底厭煩，幸運的是spring為我們提供了自動裝配的方式 只要遵循一定的規則，spring就會自動幫你裝配依賴，而不需要你手工去裝配 自動裝配...
Spring 自動裝配
bean的自動裝配 autowiring 四種型別 1.no 不做任何操作 2.byname 根據屬性名自動裝配。此選項將檢查容器並根據名字查詢與屬性完全一致的bean,並將其與屬性自動裝配 3.bytype 如果容器中存在乙個與指定屬性型別相同的bean,那麼將與該屬性自動裝配 如果存在多個該型別...