Контейнер дозволяє залежність біна таким чином:
-
ApplicationContext
створюється та ініціалізується за допомогою конфігураційних метаданих, які описують усі біни. Конфігураційні метадані можна вказати за допомогою XML, Java або анотацій. -
Для кожного біна його залежності виражаються як властивості, аргументи конструктора чи аргументи статичного фабричного методу (якщо ти використовуєш його замість звичайного конструктора). Ці залежності надаються біну під час його фактичного створення.
-
Кожна властивість або аргумент конструктора є фактичним визначенням значення, яке потрібно встановити, або посиланням на інший бін у контейнері.
-
Кожна властивість або аргумент конструктора, що є значенням, перетворюється із зазначеного формату на фактичний тип цієї властивості або аргументу конструктора. За замовчуванням Spring може перетворити значення, надане у рядковому форматі, на всі вбудовані типи, як-от
int
,long
,String
,boolean
тощо.
Контейнер Spring перевіряє конфігурацію кожного біна під час створення контейнера. Однак самі властивості біна не встановлюються доти, доки бін не створено. Біни, що належать до області видимості singleton і налаштовані на попереднє створення екземпляра (pre-instantiated) (за замовчуванням), формуються під час створення контейнера. В іншому випадку бін створюється тільки тоді, коли надходить запит. Створення біна потенційно призводить до створення графа залежності бінів, оскільки створюються та призначаються залежності біна, залежності його залежностей (і так далі). Зверни увагу, що невідповідність у вирішенні цих залежностей може виявитися запізно: тобто при першому створенні порушеного біна.
Зазвичай можна довіритися Spring у тому, що все буде зроблено правильно. Він виявляє проблеми конфігурації, такі як
посилання на неіснуючі біни та циклічні залежності під час завантаження контейнера. Spring встановлює властивості і
дозволяє залежності якомога пізніше, коли бін вже створено. Це означає, що контейнер Spring, який завантажився
правильно, може пізніше згенерувати виняток під час запиту об'єкта, якщо існує проблема створення цього об'єкта або
однієї його залежностей. Наприклад, бін генерує виняток внаслідок відсутності або неприпустимої властивості. Ця
потенційно відкладена видимість деяких проблем конфігурації є причиною того, що реалізації
ApplicationContext
за замовчуванням попередньо створюють екземпляри бінів-одинаків. Витративши деякий
час і пам'ять створення цих бінів до того, як вони дійсно знадобляться, ти виявиш проблеми з конфігурацією при
створенні ApplicationContext
, а не пізніше. Ти, як і раніше, можеш перевизначити цю поведінку за
замовчуванням, щоб біни-одинаки ініціалізувалися відкладено замість якнайшвидшого попереднього створення екземпляра.
Якщо циклічних залежностей не існує, під час впровадження одного або кількох взаємодіючих бінів до залежного біна, кожен бін, що взаємодіє, повністю конфігурується перед впровадженням до залежного біна. Це означає, що якщо бін A залежить від біна B, IoC-контейнер Spring повністю конфігурує бін B перед викликом сетера для біна A. Іншими словами, створюється екземпляр біна (якщо він не є попередньо створеним одинаком), встановлюються його залежності, і викликаються відповідні методи життєвого циклу (такі як налаштований метод init або метод зворотного виклику InitializingBean).