- 12-02-2008
Spring Framework - первые шаги (Конспект седьмой)
Конспект седьмой : Constructor versus Setter Injection (продолжение)
Сегодня мы постараемся разобраться в преимуществах и недостатках, как Constructor Injection (CI), так и Setter Injection (SI).
Во-первых, следует отметить, что предпочтительно создавать "готовый" объект со всеми инициализациями его полей в одном месте. Поэтому, использование конструктора является прозрачным и более понятным механизмом, т.к. всем разработчикам отлично видно, что и как было инициализированно в момент создания объекта.
Если существует нескольно путей создания объекта, необходимо позаботиться о наличии необходимого количества перегруженных конструкторов.
Вышеописанный метод безусловно хорош, однако при наличии большого количества полей класса (как мне кажется более 5), наличие перегруженных конструкторов может стать ночным кошмаром. Правда, мы не должны забывать и тот факт, что с точки зрения дизайна приложения, класс, содержащий такое количество параметров, вероятнее всего является слишком "тяжелым" и его необходимо подвергнуть рефакторингу - разделить на подклассы, etc. Но все же, в подобном случае, когда количество параметров велико, необходимо переходить к использованию Setter Injection.
С другой стороны, непосредственно сами разработчики Spring Framework, рекомендуют использовать именно Setter Injection, т.к. Constructor Injection может приводить к "ужасному" (messy) коду, и кроме этого Setter Injection позволяет производить переконфигурирование системы во время работы.
Следует так же отметить, что компоненты связанные с session-компонентами, в любом случае должны конфигурироваться исключительно с помощью Setter Injection – почему? Мы ответим на этот вопрос в одной из следующих лекций, когда будем рассматривать диапазоны жизненого цикла компонент (scope).
При использовании Constructor Injection, может возникнуть еще одна проблема, известная как Кольцевая Зависимость (Circular dependencies).
Представьте себе ситуацию, когда конструктор класса А требует в качестве параметра экземпляр класса B, а тот в свою очередь требует в конструкторе наличие класса A!? В этом случае, Spring Framework, не сможет "поднять" экземпляры упомянутых компонент (beans), и выбросит исключительную ситуацию: BeanCurrentlyInCreationException.
Выходом из подобной ситуации будет переход к Setter Injection. В этом случае при создании объектов, поля будут проинициализированы null и только в следующем проходе Spring выполнит Setter Injection.
Представьте себе ситуацию, когда конструктор класса А требует в качестве параметра экземпляр класса B, а тот в свою очередь требует в конструкторе наличие класса A!? В этом случае, Spring Framework, не сможет "поднять" экземпляры упомянутых компонент (beans), и выбросит исключительную ситуацию: BeanCurrentlyInCreationException.
Выходом из подобной ситуации будет переход к Setter Injection. В этом случае при создании объектов, поля будут проинициализированы null и только в следующем проходе Spring выполнит Setter Injection.
Таким образом, не существует жестких требований, заставляющих разработчиков использовать тот или иной метод. Более того, современные фреймворки, как правило поддерживают как SI, так и CI. Не является исключением в этом плане и Spring Framework. Пользуйтесь здравым смыслом и приобретенным опытом
.
.Vyacheslav Yakovenko
Spring Framework - первые шаги (Конспект шестой) :: Spring Framework - первые шаги (Конспект восьмой : Beans scope)
| Комментарии к статье "Spring Framework - первые шаги (Конспект седьмой)" (5) |
| 02-03-2009 19-18 Спасибо большое за конспекты! Ждем продолжения! |
|
|
| 24-02-2009 13-38 P.S. И надо бы ссылку на следующий конспект добавить.. |
| 24-02-2009 13-34 s/констуркторе/констуркторе/ s/проинициализиорованы/проинициализированы/ |
| 07-10-2008 17-28 Отличные статьи для новичков в ЕЕ.. Хочется продолжений |